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ABSTRACT 
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NETSIM  is  a  computer  simulation  model  written  in  the  S1MSCRIPT 
programming  language  whose  purpose  is  to  provide  a  general  simulation 
capability  for  any  network  composed  of  links  and  nodes.  The  current  use 
of  NETSIM  in  multiple  channel  deep  draft  navigation  systems  has  earned  it 
the  qualification  NETSIM/ SHIP.  The  model  was  developed  for  use  by  the 
U.S.  Army  Corps  of  Engineers  with  immediate  applications  on  the  Great  Lakes 
systems. 

Ships  are  handled  in  NETSIM/SHIP  on  a  chronological  event  basis  as  they 
engage  in  their  journey  from  origin  to  destination.  Simulation  of  ship  pro¬ 
cessing  at  system  facilities  (locks,  reaches,  etc.)  is  carried  out  through  the 
use  of  distinct  link  modules, and  channel  choice  decisions  where  alternative 
routes  exist  are  handled  by  a  decision-making  mechanism  based  on  the  calculation 
of  expected  transit  times  for  each  route. 

Required  inputs  consist  of  fleet  data,  run  and  system  size  parameters, 
and  a  description  of  the  network  configuration  and  system  entities.  Output 
produced  by  the  model  consists  of  data  for  the  formulation  of  the  channel  choice 
mechanism  in  the  first  form,  and  an  event  by  event  description  of  the  actual 
simulation  in  the  second  form.  The  latter  form  provides  a  permanent  data  base 
from  which  exactly  tailored  statistical  reports  can  be  generate 

Although  the  model  is  complete  as  it  currently  exists,  it  is  being  further 
equipped  with  extensive  capabilities  for  general,  system  wide  simulation  of  the 
Great  Lakes.  Even  without  these  capabilities,  however,  the  current  version  of 
NETSIM/SHIP  can  be  used  as  a  planning  tool  to  aid  in  the  investigation  of  sub¬ 
system  operating  characteristics. 
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The  work  described  in  this  interim  report  was  performed  by  the 
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research  was  devoted  to  the  development  of  a  simulation  model  for  applications 
on  the  inland  waterways,  and  to  the  use  of  the  model  to  study  structural  and 
nonstructural  improvements  This  report,  in  documenting  the  provision  of 
deep  draft  navigation  systems  simulation  capability,  extends  the  horizon  for 
complex  system  research  and  planning. 
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I.  INTRODUCTION 

In  June  of  1972,  the  Army  Corps  of  Engineers,  North  Central  Division 
entered  into  a  contract  with  the  Pennsylvania  Transportation  and  Traffic 
Safety  Center  for  the  development  of  a  simulation  model  that  would  facilitate 
a  systematic  analysis  of  the  capacity  of  the  Great  Lakes  Navigation  System. 
The  development  of  this  simulation  model  was  to  undergo  three  phases: 

1.  To  develop  a  LE-LO  Navigation  Simulation  model; 

2.  To  apply  the  model  to  simulation  studies  of  the  Welland  Canal 
and  proposed  alternatives  to  the  Welland; 

3.  To  revise  the  initial  simulation  model  so  as  to  include  the 
capabilities  needed  for  comprehensive  Great  Lakes-St.  Lawrence 
System  Simulations. 

This  report  presents  a  description  of  the  first  phase,  i.e.  the  LE-LO 
Navigation  Simulation  model.  The  description  encompasses  the  underlying 
conceptual  structure  of  the  model  as  well  as  the  logical  flow  of  the 
program.  A  user's  manual  is  presented  in  the  Appendix  to  describe  in 
detail  the  data  needs  and  preparation. 

A.  HISTORICAL  BACKGROUND 

The  construction  of  the  LE-LO  Navigation  Simulation  Model  dates  back 
to  the  use  of  computerized  simulation  models  on  the  inland  waterways.  The 
circumstances  leading  to  their  development  and  the  results  of  that  research 
are  reported  in  a  six-volume  technical  report  entitled  Waterway  Systems 
Simulation  (1).  The  groundwork  for  Greak  Lakes  simulation  was  laid  in 
Volume  V  of  this  series,  entitled  Simulation  of  Multiple  Channel  Deep  Draft 
Navigation  Systems  (2) .  The  model  presented  in  Volume  V  will  henceforth  be 
referred  to  as  the  MCDD  model  (Multiple  Channel  Deep  Draft) . 
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The  development  of  the  MCDD  model  was  commissioned  by  the  Corps  of 
Engineers  to  provide  simulation  analyses  of  the  Great  Lakes-St.  Lawrence 
Seaway  transportation  system.  The  study  had  two  objectives:  first,  to 
build  a  simulation  model  specirically  designed  to  simulate  the  performance 
of  a  multiple  channel  deep  draft  ship  canal  in  which  each  channel  consists 
of  a  series  of  locks  and  reaches;  and,  second,  to  formulate  a  methodology 
for  assigning  vessels  between  parallel  canals. 

The  conceptual  basis  for  the  MCDD  model's  multiple,  parallel  channel 
simulation  capability  is  its  assignment  decision  technique.  The  methodology 
employed  by  the  model  for  determining  a  vessel's  expected  transit  time 
through  a  canal  is  not  dissimilar  to  the  decision  process  that  would  be 
undertaken  by  a  rational  and  experienced  channel  controller  (i.e.  one  who 
assigns  each  vessel  to  a  channel)  When  a  vessel  approaches  the  channel 
choice  point  the  controller,  given  the  current  channel  conditions,  could 
draw  upon  his  experience  to  predict  the  vessel's  probable  transit  time 
through  each  channel  The  vessel  would  then  be  assigned  to  the  channel 
offering  the  least  expected  transit  time- 

The  fern  or  the  decision-matcing  mechanism  whether  it  be  the  channel 
controller,  the  vessel  captain  or  pilot,  or  simply  some  inanimate  information 
system  is  actually  irrelevant  as  regards  to  the  justification  for  the 
methodology  employed  by  NEIS1M/SHIP.  The  critical  assumption  is  that  a 
state-dependent  relationship  for  the  expected  transit  time  be  obtainable. 

The  MCDD  model  simulates  the  channel  controller's  experience  by  using 
a  priori  relationships  between  prior  conditions  and  subsequent  transit  times. 
These  relationships  exist  in  the  form  of  decision  functions  statistically 
derived  from  an  experience  data  base  To  develop  an  Experience  Data  Base 
(EDB) ,  a  user  arbitrarily  elects  one  canal  within  a  set  of  parallels  through 
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which  all  transits  are  to  move  Daring  a  simulation,  the  EDB  mechanisms 
produce,  as  output,  the  conditions  existing  within  each  arbitrarily 
selected  canal  when  a  vessel  approaches  the  assignment  decision  point. 
Succinctly,  the  EDB  contains  canal  conditions  prior  to  a  vessel's  transit. 

As  each  vessel  exits  a  canal,  the  EDB  mechanisms  again  produce  output — 
this  time  m  the  form  of  the  time  spent  by  a  vessel  in  transiting  a  canal, 
i.e- ,  a  vessel's  subsequent  transit  time.  The  EDB,  containing  prior  canal 
conditions  and  subsequent  transit  times,  is  statistically  analyzed  to  derive 
functions  lor  predicting  expected  transit  times.  A  function  is  derived  for 
each  parallel  canai  within  a  simulated  system.  The  set  of  functions  is  then 
included  with  the  modal  in  a  rollowing  simulation,  where  it  is  used  to 
predict  expected  transit  times. 

Thus,  using  statistically  derived  expected  transit  time  functions,  a 
vessel  is  assigned  tc  a  channel  based  upon  least  expected  transit  time. 

Once  a  vessel  is  assigned  to  a  channel,  it  receives  an  assignment  map  which 
indicates  the  sequence  of  reaches  and  locks  to  be  followed.  Using  the 
vessel's  map,  a  movement  control  mechanism  monitors  the  vessel's  course 
while  m  transit  through  the  series  of  reaches  and  locks. 

The  lock  simulator  included  m  the  MCDD  model  simulates  actual  lock 
operations  by  sampling,  at  appropriate  times,  from  seven  probability 
distributions  which  describe  the  different  time  elements  in  the  lock's 
operations.  Ihe  locks  use  an  alternating  service  queue  discipline.  The 
reach  simulator  samples  from  two  probability  distributions,  thereby  con¬ 
sidering  any  possible  effects  that  direction  of  transit  might  have  upon 
reach  transit  time-  Vessels  are  not  allowed  to  pass  other  vessels  during 


reach  transits 
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I  MCDD  mcdel ,  as  described  b>  it9  authors  is  intended  for  simulating 
alternative  channel  conngurations  for  comparative  analysis.  The  scope  of 
the  modei  does  noL  include  tne  capability  for  total  system  studies  which, 
for  some  time  (o)  has  been  considered  essential,  as,  indeed,  it  still  is  (4) 
if  alternative  waterway  improvements  are  to  be  meaningfully  evaluated.  The 
authors  suggest  modifications  chat,  if  implemented,  would  develop  the  MCDD 
mcdel  into  a  general  systems  model  capable  of  simulating,  for  example,  the 
Great  Lakes-SL  Lawrence  transportation  system.  Suggestions  are  also  given 
for  refining  the  lo^k  simulator  so  that  the  model  could  be  used  for  lock 
design  studies 

Ihe  authors  suggest  the  addition  of  three  features,  listed  as  follows, 
which  would  transf-rm  their  modei  into  an  effective  lock  design  tool: 

1  Ihe  ability  to  dmerentiate  by  vessel  size  or  weight  and  select 
appropriate  distributions. 

2  Ine  ability  to  durerantiate  by  movement  direction. 

3  Ihe  ability  to  "icck  ahead"  to  determine  the  next  vessels  to  be 
serviced  according  to  seme  operating  criterion. 

Inese  three  additional  ieatures  serve  to  increase  the  complexity  of  the 
model,  as  its  realism  is  increased-  For  increasing  the  model's  generality, 
two  additional  ieatures,  mencicned  below,  are  suggested: 

4  The  capability  to  initiate  and  terminate  vessel  movements  within 
reaches . 

5  Ihe  capability  to  simulate  the  time  spent  in  port  by  a  vessel  as 
a  iunction  of  port  Cvtauions,  facilities,  cargo,  etc. 

The  aDiiic.\  to  dmerentiate  vessels  by  their  primary  characteristics 
aiiows  research  studies  to  be  conducted  covering  the  relationships  between 
these  vessel  chaicutetistics  and  system  utilization.  Another  important 
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consequence  ot  this  texture  is  the  ability  to  study  the  effects  of  vessel 
characteristics  (especially  sue  and  speed)  in  relation  to  lock  design. 

This  relationship  becomes  increasingly  important  as  vessels  increase  in 
size  and  speed,  eime  locks  have  an  expected  life  of  around  fifty  years  (5). 

Because  ot  the  possible  etiects  of  water  flow  direction  upon  the  speed 
ot  vessels,  it  ia  dcairsble  to  be  able  to  sample  from  distinct  probability 
distributions  to  simulate  chose  effects.  Having  separate  distributions 
r.r  each  dtrecLion  also  permits  a  more  realistic  simulation  of  the 
different  volumes  of  vessel  crano.ta  moving  upstream  and  downstream. 

To  use  the  moaei  tor  lo.s.  design  studies,  the  lock  simulator  must 
closely  simulate  actual  lock  operations.  Inclusion  of  a  "service  lookahead" 
feature  provides  the  ability  to  simulate  the  actions  that  an  intelligent 
experienced  io-kmastei  would  cake  Ihese  actions  pertain  particularly  to 
the  situation  when  the  lock  la  idle,  ot  empty.  The  lockmaster  scans  the 
odjacent  reaches  and,  when  he  sees  an  imminent  arrival,  commits  the  lock, 
rscy-ting  it  necessary,  .n  order  to  minimize  the  arrival's  delay.  When 
at  living  vessels  exist  in  both  reaches  the  experienced  lockmaster  determines 
which  vessel  wnl  probably  arrive  first,  taking  into  consideration  the  time 
required  tot  recyo.-c.g,  oc.d  commits  tne  rock  to  that  vessel  expected  to 
art ive  titsc 

Io  be  able  to  e.muiae,  tor  example,  a  shipping  season  in  the  Great 
Lakes-St  Lawrence  S=.away  transportation  system,  the  model  must  be  capable 
or  beginning  its  vessels'  transits  from  different  ports  at  different  times. 
Simulation  or  the  Closing  of  the  shipping  season  requires  that  vessels  be 
ante  re  terminate  tne*r  transits  at  any  ports  In  the  system.  This  feature 
ai»o  has  the  side  Denstit  ot  allowing  a  simulation  to  begin  in  near  steady 


.-rate,  given  that  an  acceptable  definition  of  steady  state  is  available. 
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The  model  obviously  muse  include  simulators  of  all  the  facilities 
comprising  a  given  system  To  permit  the  simulation  of  the  Great  Lakes- 
St.  Lawrence  Seaway,  tor  example,  the  model  must  include  port  and  lake 
simulators,  as  well  as  its  current  lock  and  reach  simulators.  The  port 
simulator  should  have,  as  a  minimum,  the  ability  to  accept  a  vessel  and 
held  it  tor  some  random  time  period  based  upon  attributes  of  the  vessel 
and  cf  the  port  The  lake  simulator  should  be  able  to  simulate  an  actual 
lake  situation,  with  multiple  ports  and  entry/exit  channels. 

B,  THE  LE-LO  NAVIGATION  SIMULATION  MODEL 

Alter  reviewing  me  above  suggestions,  the  COE  authorized  the  PSU 
analysis  group  to  undertake  a  development  effort  whereby  these  suggestions 
wouid  be  implemented  The  resulting  model  is  designated  by  the  acronym 
NETS  1M  (.NETwork  SIMulator;  and  due  to  its  current  applications  is  further 
qualified  as  NEISiM,SHiP 

NEISiM,  Shir  nas  been  programmed  with  a  particular  eye  towards  flexi¬ 
bility  Ihis  flexibility  is  especially  due  to  four  factors.  First, 
riexibinty  is  rendered  by  the  modular  design  which  allows  the  insertion, 
removal  or  extension  or  any  program  segments  of  the  model  to  make  it 
adaptable  tor  a  g„»tn  set  ox  extenuating  circumstances.  To  emphasize  this 
modular  design  a  octet  explanation  is  provided. 

NEISiM, SHiP  is  composed  of  lour  separate  logic  modules.  The  first 
two  modules  are  concerned  with  system  initialization  and  traffic  control 
tunctim=  cespe.c.veiy  Ihe  chird  module  consists  of  four  distinct  sub- 
modules,  or.c  tot  earn  of  NEISiM/SHlk ’s  four  facilities  (lock,  lake,  reach, 
and  port;.  The  lootth  logic  module  provides  utility  programs  in  support 
ot  the  other  three  mmaj.se  Thus  the  modification  of  any  of  these  modules 
aubmoduleo;  tc  tutchet  tailor  it  ter  particular  circumstances  is 


greatly  l-jcilitated. 
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Flexibility  is  lurther  actamed  by  v/ircue  of  che  fact  that  the  model 
is  sc  implemented  on  cne  Penn  State  - omputer  racillty  such  as  to  allow 
remote  operation  or  Lhc  model  That  i=,  operation  is  not  confined  to  the 
Penn  State  campus,  but  rather  is  limited  only  by  che  location  of  a  suitable 
communications  terminal  ana  a  v- 1 ..e-g: aae  telephone  lme- 

Flexibiiity  oxa o  exists  m  Lhe  use  oi  the  computer  programming  language 
used  to  encode  Lhe  moa=l  lhe  MCDD  model  is  written  in  GPSS,  while 
NErSxM/SHiP  is  written  in  oiMSCRlPr.  GPSS  is  a  problem-oriented  language 
written  specilicaxiy  i.r  users  with  lucre  ul  no  programming  experience  and 
its  simpiiricd  strutt ute  results  m  s-.me  toss  oi  rlexlbility.  On  che  other 
hand,  SiMSCRui  requites  more  programming  skin,  but  it  is  capable  of 
representing  more  Cempxex  data  structurea  and  can  execute  more  complex 
decision  rux.es  Further,  xts  Engnsh-iike  readability  allows  a  SIMSCRIPT 
written  model  t  _  ici.c  to  a  great  extent  =s  .to  own  documentation.  Thus 
the  tiexiDimy  u  aiMSukiPI  -an  oe  eummarned  by  saying  that  in  complex 
models,  SlMSCPxPl  x»  aou  t-  proauce  a  m-xe  xompaot  model  that  requires 
less  storage  spa-e,  ana  that  gct.ctaiiy  w.i  te  executed  more  rapidly. 

Flexibility  is  a.tj  rendered  c>  tr.e  use  cl  a  three-phase  approach 
m  executing  the  m~dex  Ihesc  pha=eo  may  ptvferiy  be  termed  as  input, 
exc.ution,  ana  output  af.diyo.a  lnc  input  phase  is  discussed  first- 

A  rochet  extensive  prepataci-n  or  the  .nput  data  stream  becomes  a 
ptfetequis-te  t.  u& i t.g  the  .ti-ac  because  or  the  technical  complexity  of  the 
subject  areas  via-ii.ty  aesxgn,  commodity  transfers,  ship  scheduling,  etc.) 
ol  potent  ial  NEISlM  aHir  eppi xcac lens ,  ana  because  no  ubiquitous  data  base 
ia  available  Ihx  heart  «t  this  input  atteam  is  the  fleet  data.  NETS1M/ 
SHIP  providta  lor  trie  input  cl  theoe  licet  data  m  either  an  endogenous  or 


an  exjgehv/us  manCiei  lhe  utter  is  ot  mote  crucial  interest,  since  it 


allows  the  u»e  ol  the  output  ticm  su^h  a  complex  vessel  generation  program 
as  TOWGEN  io ;  The  input  data  scream  consisting  ot  the  fleet  data  serves 
as  the  fcitst  phase 

The  actual  simulation  using  NEISiM,  SHIP  constitutes  the  second  phase. 

This  phase  itsell  is  ccmp.sed  ot  two  sub-phases:  t.1)  the  EDB  phase  and 
(2;  the  Event  LOG  phase  Ihe  sub-phaoe  structure  or  the  second  (simulation) 
phase  is  necessitated  by  NEIaiM, SHIP 's  alternative-selection  functions. 

When,  m  transiting  a  simulated  network,  a  vessel  approaches  a  point  where 
alternative  routes  exisc,  NETS IM,  SHIP ' s  dynamic  route  determination  logic 
selects  one  ot  the  available  alternatives  on  the  basis  of  least  expected 
transit  time  The  expected  transit  time  ter  each  available  alternative  is 
calculated  by  reading  a  at  a  describing  cut  rent  traffic  conditions  to  a  set 
ol  expected  tiaiiaii  time  tufktierw.  These  expected  transit  time  functions 
contain  ccenmente  whi.h  weight  the  varices  ttatnc  conditions.  It  is 
these  .ueir.ciencs  that  are  dcn.ed  item  the  rirst,  or  EDB,  sub-phase  of 
NEToiM/ SHIP 's  simulation  phase  Ihe  EDB  phase  determines  the  coefficients 
tor  the  expected  transic  time  tautions  by  oimuiating  a  network  config¬ 
uration  with  selected  alternative  routes  removed  from  the  system.  In  this 
way,  ail  trans.is  ate  totted  to  use  a  particular  alternative  route.  Regression 
analysis  is  Lhen  osid  to  determine  the  va.ues  ot  each  coefficient  in  the 
function  tor  a  speulu  seic..~_d  alternative 

Once  aii  the  expected  tiansit  time  functions  needed  to  simulate  a 
particular  network,  have  been  derived,  tr.e  second,  or  EVENT  LOG,  sub-phase 
can  be  conducted.  Ihe  expected  tiansit  time  runctions  are  utilized  during 
the  EVENI  cOu  phase  tc  dynamically  consider  the  enacts  of  current  traffic 
conditions  up~n  expected  tranoit  time.  Ihe  EVENI-LOG  sub-phase  generates 
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a  log  oi  each  event  ^..uubtud  anting  simulation  It  is  this  event  log 
which  is  used  during  '.he  third  pr,a0e  oi  the  modeling 

Because  ui  tne  complexity  ana  antci  uiume  or  NEISIM/SHIP 's  encoded 
logit  aiiuauua,  n  wa»  decided  u  ui.vt  the  Durden  of  statistical 
evaluation  to  a  p_s t -a 1  _n  i-hoic  lhuo  the  third  phase  consists  of 
a  post-s imuiat  idti  poLcsaoi  program  whith  utiiitca  the  event  log  generated 
during  the  second  phase  t.  summer  nt  sigmucant  statistical  data. 

it  may  Ds  n^tca  that  tne  gtneiaiion  oi  an  event  log  provides  a 
secondary  advantage  .n  th  =  ..reatiun  or  a  t-eimanent,  detailed  record  of 
the  simulation  Ihe  p_st  prj.e==er  „ah  thcteicre  De  tailored  to  fit  the 
needs  ot  the  user  at.d  mat  simpiy  be  m^aiiicd  it  m-te  mrormation  is 
desired  Inc  lattet  step  a.cc  n_o  requite  a  tan  -t  the  time-consuming 


simulation  phase- 
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i;  iNPur-our. ui  description 

Fhia  chapter  ta  des i gned  t -  provide-  a  qui^k  summary  of  NETSIM's  data 
requirements  ana  explain  acme  .t  tr.e  mote  complicated  sections.  An  item 
t>>  item  dfca.iipt.cn  d  che  input  ana  octpui  data  sets  is  also  given  in  the 
NETS  IM,  SH 1 1-  USER'S  MANUAL  provided  t  nt  Appendix. 

a.  INFUl  DaIa  bAsE 

NEISiM/ SH.U ’a  ifipct  data  stream  is  broken  into  the  following  four 
.aiegjriea: 

1  Rail  po  t  odlc  -eta 
2.  c  ffi  ?  i  £  c  p <xl  citTlc.  lets 

J  &y& Lcfll  c H l i C ^  Ut&t I .pCwlb 
4  Nd'  Wcf  k  Lufii  iv.ii  dcoiviipiwis 

i  Run  p<a  c  ci  o 

Iht:  i.  rst  .Acr.!)  wi  input  aaia,  the  ten  parameters,  provides 
NElaiM,  aHif  t*ith  .r.i  lai  ..n  peti.ucr..  tc  certain  program  options ,  input 
and  c  uc  put  dev.,  ea  ,  aria  the  dcU..ik  c  c  n  r  i  Aui  at  i  :a  to  be  simulated  These 
t  CL .  llade  •  tic  Li  UJw  l  Cl£ 


a 

a  ?  w  11  t  t  c  tc  ffifll'jiatcCl 

D  . 

:ifflul 

Cll  .  V  l. 

rati  t>Fc  v >*he the.  EDS  c<  EVENI  LOG;  specification 

V 

btfvl 

..  C-  L  .. 

K  c*ti  t  ciCl  L  c-  <5  .  c»  c 

a 

1 1  mu  * 

is  (  i  u'li 

..  t  polaiic  i  ail  clliat  i'vCs  bpticll  iCStlOIi 

c 

..  ut  r 

l  -dir 

Qfc;  v  L 

1 

. 

u ti  <  l 

dt  v  )  k  d  l  ..  i  cxJgericOa  datci 

g 

ilc.-'  t 

u  .  i  .  l. 

c.  I  vcfcrei  u(Jc(.  1 1  c  I  .  efilfj  apdCmCoClCn 

h 

X 5 

fl  r  i  i  d  ci 

^’f'C  illwul  lr.il 

2.  System  size  parameters 

The  size  parameters  include  seven  data  elements  that  together  describe 
the  extent  of  the  network  being  simulated.  These  parameters  consist  of 
the  nuofcer  of  ports,  lakes,  reaches,  locks,  vessels,  nodes  and  the 
number  of  vessels  with  predetermined  itineraries. 

3.  System  entity  descriptors 

NETSIM/SHIP  includes  five  different  system  entities:  (a)  ports, 

(b)  lakes,  (c)  reaches,  (d)  locks,  and  (e)  vessels.  A  description  of  the 
data  requirements  for  each  entity  follows. 

Each  port  within  a  network  requires  five  data  elements.  The  first 
two  elements  consist  of  the  port  identification,  and  a  commodity  code 
representing  the  ability  of  the  port  to  process  the  commodity.  The  third 
element  is  a  frequency  distribution  giving  the  probabilities  of  a  vessel's 
movement  from  the  current  port  to  any  other  port  in  the  network.  This 
element  was  included  in  the  model  to  provide  a  basis  for  future  experi¬ 
mentation  of  a  vessel  schedule  based  on  random  access  of  ports.  The  fourth 
element  in  the  port  descriptors  specifies  whether  the  frequency  distribution 
for  port  turnaround  time  is  empirically  supplied  or  is  to  be  derived  from  a 
S1MSCR1PT  supplied  theoretical  probability  distribution.  The  fifth  element, 
therefore,  consists  either  of  an  empirical  frequency  distribution  or  the 
arguments  for  a  theoretical  distribution. 

A  lake  requires,  minimally,  six  data  elements.  The  first  two  elements 
comprise  the  lake  identification  and  the  number  of  nodes,  ports  included, 
associated  with  the  lake.  The  third  element  specifies  whether  the  lake  is 
one  branch  of  a  set  of  parallel  routes.  The  fourth  element  identifies  the 
lake  transit  time  distribution  as  being  either  theoretical  or  empirical. 
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The  fifth  element  Is  the  distribution  Itself  If  empirically  given  or  the 
arguments  if  theoretically  specified.  The  sixth  element  is  required  only 
if  the  simulation  run  is  of  an  EVENT  LOG  type  and  if  the  lake  is  in  a 
parallel  set.  In  such  a  case,  the  sixth  element  specifies  the  effects  of 
the  lake  conditions  in  the  calculation  of  the  expected  transit  time  for 
a  vessel  through  that  alternative.  The  seventh  element  consists  of  an 
origin-destination  (0-D)  table  providing  the  distance  between  any  two 
nodes  (including  ports)  on  the  lake. 

Each  reach  in  the  system  configuration  requires  at  least  nine  elements. 
The  first  two  elements  are  the  reach  Identification  number  and  the  length 
of  the  reach.  The  third  specifies  whether  passing  is  allowed  in  the  reach. 
The  fourth  specifies  whether  the  reach  is  part  of  a  parallel  set.  The  fifth 
element  indicates  whether  the  reach  transit  time  distribution  is  theoretical 
or  empirical.  The  sixth  and  the  seventh  elements  constitute  the  end  point 
nodes  for  the  reach  and  the  eighth  and  ninth  elements  provide  the  reach 
transit  time  distributions,  one  for  each  direction  of  travel.  If  the 
simulation  is  of  an  EVENT  LOG  type  and  if  the  reach  is  in  a  parallel  set, 
then  two  more  elements  are  required,  one  for  each  direction.  These  specify 
the  effects  of  the  reach  conditions  in  the  calculation  of  the  expected 
transit  time  for  a  vessel  through  that  alternative. 

The  first  element  of  the  set  of  lock  descriptors  is  its  identification 
number.  The  second  and  third  elements  provide  the  two  end  point  nodes  of 
the  lock  while  the  fourth  element  specifies  the  maximum  vessel  length 
permitted  in  the  lock.  The  fifth  element  indicates  whether  the  lock  is 
in  a  parallel  set  of  alternative  routes.  The  next  nine  elements  are 
associated  with  nine  time  blocks  constituting  the  lock  frequency 
distributions.  The  sixth  through  fourteenth  elements  indicate  whether 
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their  associated  time  blocks  (l.e.  distributions)  are  supplied  empirically 
or  theoretically.  The  next  nine  elements,  therefore,  provide  the  actual 
time  blocks,  either  empirical  distributions  or  theoretical  arguments.1 
Two  more  elements  are  supplied  if  the  simulation  is  of  an  EVENT  LOG  type 
and  if  the  lock  is  part  of  a  parallel  set.  These  describe  the  effects  of 
the  lock  conditions  in  the  calculation  of  the  expected  transit  time  for 
a  vessel  through  that  alternative  in  each  44V>-  ion. 

Vessel  data  can  be  supplied  either  w#"  ute  regular  input  data 
stream  or  from  an  external  input  device  simulation.  The  vessel 

data  consists  of  the  vessel  identification  if  .raber ,  its  length,  a  commodity 
code  representing  the  vessel's  load,  its  origin  port,  an  itinerary  code 
and  its  time  of  departure  from  the  origin  port.  Further,  if  the  vessel 
has  a  pre-defined  itinerary,  this  is  also  specified.  The  exact  order  of 
these  parameters  depends  on  whether  the  vessel  data  are  externally  supplied 
or  not. 

A.  Network  configuration  descriptors 

There  are  three  data  tables  required  by  NETSIM/SHIP  that  together 
comprse  a  map  of  the  network  configuration  being  simulated.  The  first, 
the  TABLE  OF  NEXT  NODES,  is  essentially  an  Origin-Destination  (0-D)  matrix 
which  also  provides  information  regarding  the  availability  of  alternative 
routes.  The  FACILITIES  ID  TABLE,  the  second  required  data  table,  provides 
the  identification  number  for  each  facility  within  a  network  configuration. 
Whenever  a  configuration  contains  alternative  parallel  routes,  these 
alternatives  are  described  in  the  third  table,  the  PARALLEL  FACILITIES  TABLE. 

^ETSIM/SHIP  can  currently  differentiate  the  locking  times  between  three 
vessel  classes. 


14 


If  the  configuration  consists  of  alternative  parallel  routes,  a  fourth 
table,  ALTERNATIVE  WIDE  COEFFICIENTS,  is  also  required.  This  table 
describes  the  effects  of  certain  system  attributes  in  the  calculation  of 
the  expected  transit  time  functions. 

The  TABLE  OF  NEXT  NODES  can  be  thought  of  as  two  separate  sections, 
the  first  of  which  is  an  0-D  matrix  (refer  to  Figure  1).  The  first  row 
of  the  table  contains  the  identification  number  of  every  port  within  the 
network  configuration  being  simulated  (column  1  of  row  1  must  be  set 
to  0) .  This  first  row  identifies  every  possible  destination  within  a 
network  (vessels'  voyages  must  always  terminate  at  ports).  The  table's 
first  column  contains  the  identification  number  for  every  node  (ports  as 
well  as  non-port  nodes)  within  a  network  configuration.  All  network  nodes 
are  included  in  the  first  column  because,  during  simulation,  it  is  possible 
for  every  node  to  serve  as  an  intermediate  origin,  from  which  a  vessel 
seeks  a  route  to  its  destination.  There  is  no  required  order  in  which 
identification  numbers  are  given,  either  in  the  first  row  or  the  first 
column,  which  means  that  the  upper-left-to-lower-right  diagonal  does  not 
necessarily  contain  all  zeroes.  The  body  of  the  table  is  made  of  the 
identification  numbers  of  the  next  nodes  to  which  vessels  must  transit 
in  sailing  from  their  current,  or  origin,  nodes  (column  1)  to  their 
destination  ports  (row  1).  The  second  section  of  the  TABLE  OF  NEXT  NODES 
is  identical  to  the  first  section,  but  only  in  its  first  row  and  its  first 
column.  The  body  of  the  second  section  contains  identification  numbers, 
not  of  next  nodes,  but  of  sets  of  alternative  parallel  routes.  When  a 
network  configuration  contains  alternative  parallel  routes,  they  are  grouped 
into  sets  and  each  set  is  assigned  a  unique  identification  number.  It  is 
these  identification  numbers  that  comprise  the  body  of  the  second  section. 
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Section  Two 
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Figure  1.  Table  of  Next  Nodes 
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If  a  vessel  has  a  set  of  alternative  routes  to  choose  from  in  sailing  from 
its  current  node  (the  first  column)  to  its  destination  port  (the  first  row), 
the  identification  number  of  the  set  of  alternatives  is  entered  in  the  table. 
If  there  are  no  alternatives  available  to  a  vessel,  a  0  (zero)  is  entered. 

For  a  simulated  network  configuration  which  contains  no  sets  of  alternative 
parallel  routes,  the  body  of  the  second  section  contains  all  zeroes.  The 
second  section  nonetheless  must  be  entered  with  the  first  section  into  the 
input  data  stream. 

The  FACILITIES  ID  TABLE  (see  Figure  2)  contains  the  identification 
number  of  each  facility  in  a  network  configuration.  It,  as  are  the  other 
two  data  tables  discussed  in  this  section,  is  read  into  the  input  data 
stream  by  rows.  The  first  row  of  the  FACILITIES  ID  TABLE  contains  an 
identification  number  for  every  node  in  the  network,  as  does  the  first 
column.  The  first  row,  first  column,  position  is  0  (zero).  The  body  of 
the  table  is  made  up  of  the  identification  numbers  of  the  network  links 
through  which  vessels  transit  in  sailing  from  a  current  node  (the  first 
column)  to  a  next  node  (the  first  row). 

Immediately  following  the  FACILITIES  ID  TABLE,  the  PARALLEL  FACILITIES 
TABLE  (Figure  3)  is  given  if  the  system  consists  of  parallel  routes.  Each 
row  of  the  table  may  be  of  a  different  length,  depending  upon  the  number  of 
links  comprising  the  alternative  route  described  b>  that  row.  The  number 
of  rows  in  the  table  is  determined  by  the  total  number  of  alternative 
parallel  routes  included  in  the  simulated  network  configuration.  Every  row 
in  the  table  has  its  first  four  columns  in  common  with  the  table's  other 
rows.  Column  1  contains  the  identification  number  of  the  set  of  parallel 
routes.  For  example,  if,  between  node  X  and  node  Y,  there  are  three 
alternative  parallel  routes  available,  these  three  routes  are  grouped  and 
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Figure  2.  FACILITIES  ID  TABLE 
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referred  to  as  set  Z.  The  row's  second  column  contains  the  number  of 
alternatives  comprising  the  set.  For  this  example,  column  two  is  3  (three). 
Column  three  contains  a  number  identifying  which  alternative  within  the 
set  is  to  be  used  during  an  EDB  run  as  the  selected  traffic-bearing  route. 

In  the  example,  if  the  routine  described  in  the  second  of  the  three  rows 
describing  the  set  is  selected  as  the  traffic-bearing  route,  column  three 
contains  a  2  (two),  referring  to  the  second  of  the  three  rows.  The  fourth 
column  contains,  possibly,  a  different  value  for  each  row  in  the  table. 

The  value  gives  the  number  of  nodes  (ports  and  non-port  nodes)  included  in 
the  route  described  by  the  row.  Each  alternative  route  begins,  and  ends, 
with  a  node  identification  number.  Therefore,  the  minimum  value  possible 
for  column  four  is  2  (two  end  nodes  bounding  a  link).  The  row's  columns 
after  the  fourth  are  determined  by  the  number  of  links  comprising  the 
alternative  parallel  route  described  by  the  row.  The  total  number  of 
columns  in  a  row  is  given  by  adding  3  (.three)  to  twice  the  number  of  nodes 
in  the  parallel  route  (given  in  Column  4),  As  an  illustrative  example,  a 
table  describing  a  set  of  alternative  parallel  routes  may  be  given  as 
follows: 


Z  3  2  2  Nx  L  N2 

Z  3  2  3  Nl  L2  N  N2 

Z  3  2  2  N.  L.  N- 

14  2 

The  N's  and  L's  refer  to  nodes  and  links  respectively. 

Notice  first  that,  since  there  are  three  alternative  routes  in  the  set, 
there  are  three  rows  in  the  table.  The  order  in  which  the  rows  are  given 
is  arbitrary  and  non-critical.  The  first  column  of  each  row  contains  Z, 


the  set  Identification  number.  The  number  of  alternative  routes  in  the 
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set,  3  is  in  Che  second  column  of  each  row.  For  a  hypothetical  EDB  run, 
the  alternative  given  in  the  second  of  the  three  rows  is  selected  as  the 
traffic-bearing  route,  so  that  column  3  of  each  row  contains  a  2  (two). 

The  alternative  described  by  the  first  row  contains  2  (two)  nodes,  giving 
column  4  of  row  1  a  value  of  2.  Adding  3  (three)  to  twice  the  number  of 
nodes,  indicates  that  row  1  has  a  total  of  seven  columns.  The  last  three 
columns  therefore  give  the  identification  numbers  of  the  two  nodes  and  the 
identification  number  of  the  link  which  they  bound.  The  first  node  ("first" 
here  refers  to  the  node  located  at  the  upstream  end  of  the  channel)  has  the 
identification  number  N^.  This  is  given  in  column  5.  Column  6  gives  the 
identification  number,  L^,  of  the  link  joining  the  route's  two  nodes. 

Column  7  contains  N£,  the  last  link's  identification  number.  The  second  row 
of  the  table  is  prepared  in  the  same  manner.  Notice  that  the  route  contains 
3  (three)  nodes,  given  in  column  4.  The  second  row,  therefore,  has  nine 
columns.  Column  5  contains  the  first  link's  identification  number, 

(note  that  all  three  alternative  routes  begin  and  end  with  the  same  nodes) . 
Column  6  contains  the  identification  number,  L ^  of  the  link  connecting  the 
first  node  with  the  second  node,  N^»  whose  identification  number  is  given 
in  column  7.  Column  8  contains  the  identification  number,  L^,  of  the  link 
connecting  N^  with  the  last  node,  N^,  given  in  column  9.  The  third  and  final 
row  of  the  table  is  prepared  in  the  same  manner. 

The  final  table  of  data  included  with  the  input  data  stream  is  the 
ALTERNATIVE  WIDE  COEFFICIENTS  which  supplies  coefficients  for  expected  transit 
time  functions.  The  table  is  optional  and  is  included  only  with  an  EVENT  LOG 
run  simulating  a  configuration  which  contains  alternative  parallel  routes. 

The  data  supplied  in  this  table  provide  coefficients  for  factors  summarized 
over  an  entire  parallel  route  as  opposed  to  the  other  coefficients  which 
are  concerned  with  individual  links  within  a  route. 
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B.  OUTPUT  DATA  BASE 

NETSIM/SHIP  produces  cwo  different  types  of  data  bases.  The  first 
data  base,  the  EDB,  produces  essentially  two  forms  of  data:  first,  that 
which  gives  prior  conditions  at  a  link  before  a  vessel  starts  its  transit 
and,  second,  that  which  gives  the  subsequent  arrival  and  exit  times  for  the 
vessel.  These  data  are  analyzed,  using  regression  techniques,  to  derive 
functions  describing  the  relationship  between  current  conditions  within  a 
link  and  a  vessel's  subsequent  transit  time  through  that  link.  An  EDB 
record  is  written  for  each  link  within  a  selected  traffic-bearing  route  at 
the  time  a  vessel  arrives  at  one  of  the  route's  two  boundary  nodes.  These 
records  describe  the  currently  existing  conditions  in  the  links.  As  a 
vessel  moves  through  each  of  the  links  comprising  the  route,  a  second  record 
is  written  for  each  link  which  gives  the  vessel's  arrival  time  and  its 
exit  time.  The  exact  format  in  which  the  records  are  written  is  adequately 
described  in  the  User's  Manual  (see  Appendix  A)  and,  to  prevent  duplication, 
is  not  discussed  here. 

NETSIM/SHIP's  second  type  of  output  data  base,  the  EVENT  LOG,  consists 
of  records  that  describe  every  event  occurrence.  The  basic  datum  in  the 
EVENT  LOG  records  is  a  four-digit  event  code  which  encodes  the  exact 
sequence  of  events  and  conditions  which  leads  to  the  occurrence  of  a 
particular  event.  The  four  digit  codes,  with  their  Interpretations,  and 
the  format  of  the  EVENT  LOG  records  are  detailed  in  the  User's  Manual. 
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III.  MODEL  STRUCTURE 

The  following  discussion  on  NETSIM/SHIP's  structural  characteristics 
is  broken  into  four  subdivisions  to  correspond  with  each  of  the  model's 
four  logic  modules.  Each  subdivision  includes  a  detailed  discussion  on 
the  logic  that  makes  up  that  particular  subdivision's  module,  as  well  as 
a  summary  flaw  chart  of  the  logic  process. 

A.  INITIALIZATION  MODULE 

The  initialization  of  NETSIM/SHIP's  values  for  a  simulation  run  is 
accomplished  through  the  ROUTINE  FOR  INITIALIZATION,  the  one  routine  com¬ 
prising  the  initialization  module.  The  routine's  logic  is  straightforward, 
being  concerned  primarily  with  reading  in  the  input  data  stream.  An 
illustration  of  the  routine's  logic  flow  is  given  in  Figure  4. 

The  initialization  routine  first  reads  in  parameters  needed  by  the 
model  to  arrange  for  certain  options  during  the  simulation  run  and  to 
define  the  network  configuration  being  simulated.  These  parameters,  along 
with  the  rest  of  the  input  data  stream,  are  discussed  in  detail  in  the 
Appendix. 

The  initialization  module  determines  whether  the  network  configuration 
being  simulated  contains  any  ports,  lakes,  reaches  and/or  locks.  Then,  for 
each  port,  lake,  reach  and/or  lock  in  the  configuration,  the  associated 
attributes  of  each  entity  are  read  in. 

NETSIM/SH1P  has  two  modes  through  which  data  describing  the  fleet  to 
be  simulated  may  be  provided.  The  data  provided  through  the  two  modes  are 
basically  identical.  There  are  format  variations,  however,  and  these  are 
described  in  detail  in  the  Appendix.  The  first  of  the  two  modes  provides 
the  fleet  data  long  with  the  regular  input  data  stream.  In  this  first  mode. 


Flgur*  4.  Central  Logic  Flow  of  the  ROUTINE  FOR  INITIALIZATION 


READ  IN  EACH  VESSEL'S 
DATA  AND  SCHEDULE  EACH 
VESSEL  TO  EXIT  PORT 


7 


Figure  4.  (Continued) 
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the  initialization  routine  reads  in  each  vessel's  attribute  data  and 
assigns  each  vessel  to  its  initial  port  for  the  beginning  of  the  simulated 
shipping  season.  In  the  second  mode,  the  fleet  data  are  provided  via  an 
external  input  unit.  The  data  are  read  in  during  simulation  in  order  of 
the  vessels'  port  exits. 

Finally,  the  initialization  routine  reads  in  data  tables  that  describe 
the  network  configuration — a  tabular  network  map,  in  other  words.  These 
tables  include  the  TABLE  OF  NEXT  NODES,  the  FACILITIES  ID  TABLE,  and,  if 
the  network  configuration  being  simulated  contains  any  parallel  facilities, 
the  PARALLEL  FACILITIES  TABLE. 

B.  TRAFFIC  CONTROL  MODULE 

With  all  the  necessary  data  read  in,  the  actual  simulation  begins  with 
the  earliest  scheduled  port  exit.  The  EVENT  FOR  PORT  EXIT  transfers  program 
control  to  the  traffic  control  module,  where  the  ROUTINE  MOVEMENT  CONTROLLER 
and  the  ROUTINE  ALTERNATIVE  SELECTOR  determine  the  vessel's  route  and  assign 
the  vessel  to  the  first  link  (facility)  on  its  route.  This  control  transfer, 
as  well  as  the  other  inter-module  relationships  within  NETSIM/SHIP  is 
illustrated  in  Figure  5. 

As  each  vessel  leaves  its  initial  port  at  the  beginning  of  the  simulated 
shipping  season,  it  is  the  traffic  control  module  which  determines  the  route 
to  be  followed  to  the  vessel's  destination  port.  As  a  vessel  transits  a 
link  on  its  route,  the  traffic  control  module  is  invoked  to  determine  the 
vessel's  next  link.  The  traffic  control  module  then  transfers  program  control 
to  the  appropriate  link  module.  These  back-and-forth  control  transfers,  as 
illustrated  by  Figure  6,  continue  until  the  end  of  the  simulation  period. 
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INITIALIZATION  MODULE 


Figure  5.  Interrelationships  Among  NETSIM/SHIP  Modules 
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1.  THE  ROUTINE  MOVEMENT  CONTROLLER 

The  MOVEMENT  CONTROLLER  roucine  has,  as  it9  basic  function,  the 
selection  of  a  vessel's  next  link  It  performs  this  function  by  accessing 
a  vessel's  map  attributes  which  reveal  a  vessel's  current  location. 

Knowing  a  vessel's  current  location  and  its  destination,  the  MOVEMENT 
CONTROLLER  references  the  system  map  (made  up  of  the  TABLE  OF  NEXT  NODES, 
the  PARALLEL  FACILITIES  TABLE,  and  the  FACILITIES  ID  TABLE)  to  determine 
the  next  link  through  which  a  vessel  is  to  transit  in  order  to  reach  its 
destination  (refer  to  Figure  7) , 

Each  vessel's  map  attributes  are  updated  whenever  the  vessel  invokes 
the  MOVEMENT  CONTROLLER.  A  vessel's  map  includes  identification  numbers  for 
the  following  four  nodes:  (1)  PREVIOUS  NODE,  (2)  CURRENT  NODE,  (3)  NEXT 
NODE,  and  (4)  DESTINATION  A  vessel's  current  location  is  always  given  by 
its  previous,  current,  and  next  nodes.  Its  position  is  kept  current  by 
updating  these  three  map  attributes  as  the  vessel  progresses  along  its 
route.  The  node  identification  number  stored  as  a  vessel's  PREVIOUS  NODE 
is  replaced  with  the  identification  number  of  the  vessel's  CURRENT  NODE. 

The  identification  number  of  the  CURRENT  NODE  is,  in  turn,  replaced  with 
that  of  the  vessel's  NEXT  NODE  At  this  point  in  the  map  updating,  it  is 
possible  to  determine  whether  a  vessel's  current  location  is  its  destination 
port.  If  a  vessel's  CURRENT  NODE,  NEXT  NODE,  and  DESTINATION  all  contain 
the  same  node  identification  number,  the  vessel  has  arrived  at  its  destination 
port  and  the  MOVEMENT  CONTROLLER  transfers  program  control  to  the  port  module. 
If  the  CURRENT  NODE,  NEXT  NODE,  and  DESTINATION  are  not  equal,  the  MOVEMENT 
CONTROLLER  continues  to  determine  a  vessel's  updated  NEXT  NODE. 

The  support  module  is  invoked  to  search  the  TABLE  OF  NEXT  NODES,  one  of 
the  three  tables  comprising  the  system  map.  From  the  TABLE  OF  NEXT  NODES,  the 
MOVEMENT  CONTROLLER  learns  the  identification  number  of  a  vessel's  next  node. 


as  well  as  whether  a  vessel  is  raced  with  alternative  parallel  routes. 

If  there  are  no  paralleL  alternatives  available  to  a  vessel  at  its  current 
location,  the  MOVEMENT  CONTROLLER  determines  the  identification  number  of 
the  vessel's  next  link  and  ttansiers  program  -ontrol  to  the  appropriate 
link  module,  if  there  are  alternat  1  vea  turn  which  a  vessel's  next  link 
may  be  selected,  the  MOVEMENI  CONTROLLER,  using  the  ALIERNAI IVE  SELECTOR 
routine,  determines  the  one  alternative  offering  the  least  expected  transit 
time.  From  this  alternative  route  with  the  least  expected  transit  cime, 
the  MOVEMENT  CONTROLLER  selects  a  vessel's  next  link  and  transfers  program 
control  to  the  appropriate  link  module  On.e  a  vessel  is  transitting  a 
route  which  is  one  of  a  set  of  parallel  alternatives ,  the  MOVEMENT  CONTROLLER 
directs  its  transit  by  rererencing  the  PARALLEL  FACILITIES  TABLE,  which 
contains  the  identi f 1  oat  ion  number  cl  ever,  n.de  and  link  comprising  an 
alternative  rouce 

2.  The  ROUIINE  ALIERNAIiVE  SELECIOR 

The  sole  function  jt  the  ALTERNATIVE  SELECIOR  routine  is  to  select  one 
of  a  set  of  alternative  parallel  r-ute=  m  a  vessel  to  transit,  using 
least  expected  transit  time  as  the  .ntari.n  tor  selection  The  ALTERNATIVE 
SELECIOR  iitst  examines  ea.b  alternative  route  to  determine  whether  any  of 
the  routes  contain  a  lock  whj.cn  .&  snsu  '.j  aiocmmodace  the  vessel  (see 
Figure  8).  If  an>  alternative  ^.-n  a.ns  a  i-.ck,  that  alternative  is 

removed  from  consideration  and  the  select i_n  is  made  from  the  remaining  routes. 

The  expected  transit  time  tot  ea.h  ovc.iible  alternative  is  com  ited  by 
the  ALTERNATIVE  SELECTOR  usir.g  expe.ied  Uo'isi:  time  functions  which  include 
weighted  measures  of  existing  train  conditions  within  each  link  of  the 
alternatives  The  weights,  or  oeti ic tents ,  for  the  factors  included  in  the 
expected  transit  time  functions  ate  detived  through  regression  analysis  of 
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the  Experience  Data  Base  (EDB;  The  ED6  is  generated  by  a  seneo  of 
preliminary  simulation  runs  wherein  ail  transits  are  directed  through  selected 
alternative  parallel  routes.  The  expected  transit  time  functions  also  take 
transit  direction  into  consideration  s.nce  the  impact  upon  expected  transit 
time  of  existing  link  traffic  conditions  is  dependent  upon  chat  tratnc's 
proximity  to  the  subject  vessel. 

After  computing  an  expected  transit  time  for  each  available  alternative 
parallel  route,  the  ALTERNATIVE  SELECTOR  then  chooses  that  alternative  with 
the  least  expected  transit  time  as  the  one  to  be  transited.  An  index, 
indicating  the  location  within  the  PARALLEL  FACILITIES  TABLE  of  the 
description  of  the  selected  alternative,  is  returned  to  the  MOVEMENT  CONTROLLER, 
along  with  program  control.  The  MOVEMENT  CONTROLLER,  now  knowing  which 
alternative  will  yield  the  least  expected  transit  time,  selects  the  vessel's 
first  link  on  that  alternative  route  and  transfers  program  control  to  the 
appropriate  link  module. 

C.  LINK  MODULE (s) 

The  link  module  may  be  a  single  Aink  model  or  it  may  contain  many  such 
models.  The  quantity  depends  upon  the  parti :uiar  application  The  current 
NETSIM/SHIP  implementation  includes  the  f  ’ilowing  three  link  models: 

(1)  lock,  (2)  reach,  and  (31  -ake  Each  ct  these  three  link  models,  along 
with  NETSIM/SHIP's  port  model  and  tht  vessel  entity,  are  discussed  below 

1.  LOCK:  a  Link  Module 

For  obvious  reasons,  the  lock  module  is  considerably  more  complicated 
than  the  reach  and  lake  modules  NEISIM/SHIP's  lock  module  builds  upon  the 
module  developed  for  the  NCDD  model,  adding,  among  others,  a  service  look¬ 
ahead  feature.  The  service  look-ahead  feature  gfves  the  look  model  the 


capability  to  commit  the  lock  co  one  of  two  vessels  based  upon  an  expected 
arrival  time  in  the  chamber  for  each  vessel  Basically,  this  feature  simu¬ 
lates  the  decision  process  of  an  experienced  rational  lockmaster  who,  seeing 
a  vessel  approaching  his  lock  from  either  end,  must  decide  whether  it  is 
better  to  recycle  the  chamber  while  empty  if  necessary  co  serve  one  vessel, 
or  to  leave  the  chamber  as  is  to  serve  the  other  vessel  NETSiM/ SHIP 's 
implementation  of  the  service  look-ahead  feature  is  based  upon  SIMSCRIPT's 
FOR  statement  which  allows  access  to  information  concerning  upcoming  events, 
With  the  FOR  statement,  NETSIM/SHIP  can  determine  whether  an  arrival  at  the 
lock  is  imminent  and  the  exact  time  at  which  the  arrival  is  to  occur  Given 
this  information,  the  model  can  determine  which  committment  would  tend  to 
minimize  a  vessel's  transit  time 

A  similar  feature  Included  in  NETS1M/ SHIP 's  lock  model  simulates  an 
experienced  rational  lockmaster's  decision  process  in  deciding  whether  to 
recycle  the  chamber  empty  to  receive  a  vessel  which  is  approaching  an  idle 
lock.  This  feature  is  referred  to  as  the  recycle  iook-ahead  reature  The 
model  determines  whether,  upon  a  vessel's  arrival  at  the  idle  lock.,  the 
chamber  has  been  idle  long  enough  to  have  recycled  berore  the  vessel  arrived 
If  it  has  been  idle  long  enough,  the  model  assumes  that  an  experienced  lock- 
master  would  have  recycled  having  seen  the  approaching  vessel,  and  instan¬ 
taneously  recycles  the  chamber  in  order  to  simulate  the  lockmaster’s  a.tion 

The  lock  model  includes  nine  distributions  for  describing  time  delays 
Seven  of  the  first  nine  distributions  are  direction-differentiated,  sc  that 
there  are  actually  sixteen  time  distributions  used  m  the  model  Figure  9 
describes  the  nine  time  elements  in  relation  to  the  physical  layout  of  the 
lock  and  Table  1  provides  a  detailed  description  Ihe  nine  time  elements  are 
used  throughout  seven  different  logic  routines  that  comprise  NETSIM, SHIP'S 
lock  module.  Each  of  the  seven  routines  is  discussed  below 


Figure  9.  Schematic  of  Simulated  Locking  Time  Events 
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TABLE  i  DESCRIPTION  OF  LOCKING  TIME  EVENTS 


EVENT  NAME  DESCRIPTION 


A. 

MOVING  ENTRY 

into  the  look  chamber  from  the  Clear  Point  at  the 
end  of  the  entry  throat- 

Begins : 

when  the  bow  of  the  ship  passes  the  Clear  Point 

Ends : 

when  the  gates  begin  to  close  astern  of  the  ship 

B. 

QUEUED  ENTRY 

into  the  lock  chamber  from  the  head  of  the  queue 
adjacent  to  the  Clear  Point 

Begins : 

when  the  gates  are  fully  open  and  the  chamber  is 
free 

Ends : 

when  the  gates  begin  to  close  astern  of  the  ship 

C. 

MOVING  APPROACH 

ENTRY 

from  the  Clear  Point  to  a  position  in  the  entry 
throat  just  clear  of  the  entry  gate 

Begins : 

when  the  tow  of  the  sh.p  parses  the  Clear  Point 

Ends : 

when  the  ship  cornes  to  rest  in  the  entry  throat 

D. 

STATIONARY  APPROACH 

ENTRY 

from  the  head  or  die  queue  adjacent  tc  the  Clear 

Point  to  a  position  in  the  entry  throat  just  clear 
of  the  entry  gate- 

Begins : 

when  the  tow  of  the  ship  passes  the  Clear  Point 

Ends : 

when  the  ship  comes  to  rest  in  the  encry  throat 

E. 

SHORT  ENTRY 

i iro  the  lock  chamber  from  a  stationary  position 
just  clear  of  the  entry  gate  in  the  entry  throat 

Begins : 

wnen  the  gates  are  iully  open  and  the  .h amber  is  free 

Ends : 

wien  the  gates  begin  to  close  astern  of  the  ship 

F. 

LOCKAGE 

or  a  ship  at  res'  m  the  .hamber 

Begins : 

when  the  en*.  ry  ga^es  begin  to  :lcs=  as-.ern  or 
the  shit. 

Ends : 

when  the  ex’t  ga  es  are  fully  opened  atter  the 
change  in  water  -ei 

G 

CHAMBER  EXIT 

tr.m  chamber  •  .  pjsitiwn  where  the  ship's  s;ern 
clears  the.  exit  gate. 

Begins : 

when  the  exit  ga^es  are  tally  opened  after  the 
change  : n  water  eve I 

Ends : 

wnen  the  ship's  stern  is  clear  or  the  exit  gate 

H. 

THROAT  EXIT 

from  position  where  the  ship's  stern  clears  the  exit 
gate  til's  Cieac  Point  at  the  end  oi  the  exit  throat 

Begins : 

wnen  tne  ship's  stetn  ,s  clear  ot  the  exit  gate 

Ends : 

when  the  stern  at  the  ship  passes  the  Clear  Point 

i . 

RECYCLE 

ot  che  water  level  with  no  ship  in  the  chamber 

Begins : 

when  the  gates  begin  to  close 

Ends : 

when  the  opposite  gates  are  tully  open  to  receive  an 
incoming  ship 
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a.  ROUTINE  TO  ARRIVE  AT  LOCK 

There  are  basically  three  movements  that  can  occur  upon  a  vessel's 
arrival  at  a  lock.  The  arriving  vessel  can  (1)  enter  the  near  queue, 

(2)  begin  moving  into  the  short-entry  position,  or  (3)  begin  moving  into 
the  chamber.  The  movement  made  by  a  particular  vessel  depends  upon  current 
lock  traffic  conditions.  Determining  the  current  status  of  these  conditions 
occupies  the  major  portion  of  the  ARRIVE  AT  LOCK  routine's  logic.  A 
summarized  flow  chart  of  the  logic  is  given  in  Figure  10. 

If  the  lock's  near  queue  is  occupied,  an  arriving  vessel  automatically 
enters  that  queue.  If,  however,  the  near  queue  is  empty,  the  near  throat 
is  checked.  If  there  is  a  vessel  here,  regardless  of  direction  of  transit, 
the  arrival  vessel  joins  the  near  queue.  If  the  near  throat  is  also  empty, 
the  logic  checks  the  status  of  the  chamber.  The  chamber's  status  can  be 
either  (1)  empty,  (2)  contains  a  vessel  moving  in  the  same  direction,  or 

(3)  contains  a  vessel  moving  in  the  opposite  direction.  If  the  chamber  is 
empty,  only  the  water  level  remains  to  be  checked.  If  the  water  level  in 
the  chamber  is  properly  adjusted,  the  arriving  vessel  begins  moving  into 
the  chamber.  If  the  water  level  is  improper  upon  a  vessel's  arrival, 
further  checking  is  required  in  order  to  make  the  decision  whether  to 
recycle  the  chamber  empty.  If  the  lock's  far  throat  is  empty,  the  lock's 
far  queue  is  also  checked.  If  the  far  queue  is  also  empty,  the  lock  model's 
service  look-ahead  feature  is  invoked  (Actually,  this  feature  can  be  included 
or  omitted  according  to  the  user's  wishes.  Discussion  here  assumes  its 
use.)  to  check  the  next  reach  for  an  imminent  arrival.  If  there  is  an 
imminent  arrival  from  the  next  reach,  the  service  look-ahead  logic  compares 
the  times  at  which  the  two  vessels  could  be  expected  to  be  in  tie-up  position 


inside  the  chamber.  The  lock  is  committed  to  that  vessel  with  the  earlier 
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Figure  10.  General  Logic  Flow  of  the  ROUTINE  TO  ARRIVE  AT  LOCK 
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expected  tie-up  time,  beginning  a  recycle  immediately  if  the  current 
arrival  vessel  is  expected  to  be  earlier.  If  the  approaching  vessel  from 
the  next  reach  has  the  earlier  expected  tie-up  time,  the  current  arrival 
vessel  enters  the  near  queue.  If  there  is  no  imminent  arrival  in  the  next 
reach,  the  chamber  begins  recycling  immediately  and  the  current  arrival 
vessel  moves  into  its  entry  throat,  either  into  the  short-entry  position 
or  directly  into  the  chamber,  depending  upon  the  chamber  recycle  time. 

If  the  lock's  far  queue  is  not  empty,  the  arrival  vessel  moves  into  the 
near  queue  without  making  use  of  the  service  look-ahead  feature.  If  the 
far  throat  contains  a  vessel  moving  toward  the  current  arrival  vessel, 
i.e  ,  into  the  chamber,  the  current  arrival  vessel  joins  the  near  queue. 

If  the  vessel  in  the  far  throat  is  moving  in  the  same  direction  as  the 
current  arrival  vessel,  the  logic  checks  the  far  queue,  etc.,  as 
described  above. 

b.  EVENT  TO  EXIT  QUEUE 

When  traffic  conditions  ate  such  that  a  vessel,  which  is  currently 
in  a  queue,  can  leave  that  queue,  there  are  two  movements  possible  for  the 
vessel-  It  is  the  function  oi  che  EVENT  TO  EXIT  QUEUE  to  investigate  lock 
traffic  conditions  and  to  schedule  the  occurrence  of  one  of  the  two 
possible  movements.  The  logic  for  this  Investigation  is  illustrated  in 
Figure  11.  If  the  chamber  is  empty  and  the  water  level  is  proper,  the 
vessel  can  move  from  its  queue  directly  into  the  chamber.  If  the  chamber 
is  empty  but  the  water  is  not  at  the  proper  level,  the  logic  must  determine 
whether  the  chamber  is  currently  recycling  or  is  currently  scheduled  to 
begin  recycling.  If  the  chamber  is  neither  currently  recycling  nor  is 
currently  scheduled  to  begin  recycling,  an  error  has  occurred.  The  logic 
of  NETSIM/SHIP's  lock  module  is  designed  in  such  a  way  that  a  vessel  will 
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Figure  11.  General  Logic  Flow  of  the  EVENT  TO  EXIT  QUEUE 
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never  exit  a  queue  when  the  chamber  is  empty  and  the  water  is  at  the  wrong 
level  unless  the  chamber  is  already  recycling  or  is  about  to  begin  recycling. 
In  the  case  where  a  vessel  exits  a  queue  and  there  is  a  vessel  in  the  chamber, 
the  former  queued  vessel  moves  into  the  short-entry  position. 

c.  EVENT  TO  MOVE  TO  SHORT-ENTRY  POSITION 

The  EVENT  TO  MOVE  TO  SHORT-ENTRY  POSITION  is  included  in  the  lock  module 
to  allow  for  the  situations  that  permit  a  vessel  to  enter  a  throat  before  the 
chamber  is  ready  to  receive  it-  The  logic  that  determines  when  such  a  situ¬ 
ation  exists  is  contained  in  the  ocher  routines  of  the  module,  so  that  the 
MOVE  TO  SHORT-ENTRY  POSITION  logic  is  negligible.  The  event  is  necessary  as 
a  separate  routine  in  order  to  provide  a  record  of  the  short-entry  movements 
made  during  simulation 

d  EVENT  TO  TRANSIT  THROAT 

The  EVENT  TO  TRANSIT  THROAT  actually  consists  of  two  subroutines. 

Since  a  lock  has  two  throats — an  entry  throat  and  an  exit  throat  for  each 
vesseL — the  logic  describing  the  two  different  transits  are  different.  The 
first  throat  transited  by  a  vessel  brings  the  vessel  into  the  lock  chamber, 
while  the  second  throat  transit  brings  a  vessel  to  the  lock's  clear  point, 
where  the  network's  next  link  begins. 

For  the  situation  where  a  vessel  is  transiting  its  entry  (or  first) 
throat  of  a  lock,  the  TRANSIT  THROAT  logic  is  relatively  simple.  As 
illustrated  in  Figure  12,  the  vessel  moves  into  its  tie-up  position  inside 
the  lock  and  the  chamber  begins  its  process.  On  the  other  hand,  the  logic 
tor  a  vessel's  second  throat  transit  is  quite  complicated. 

The  reason  for  the  complexity  in  the  logic  used  to  simulate  a  vessel's 
exit  from  a  lock  is  that  a  decision  must  be  made  as  to  whether  to  admit  a 
vessel  into  the  throat  from  which  the  current  vessel  is  now  leaving. 
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Figure  12,  General  Logic  Flow  of  the  EVENT  TO  TRANSIT  THROAT 
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Figure  12  also  illuscrates  this  process.  If  the  lock's  chamber  contains 

a  vessel,  the  chamber  must  have  recycled  empty  to  receive  the  vessel.  This 

leaves  nothing  for  the  TRANSIT  THROAT  logic  to  do,  since  the  lockmaster 

logic  has  already  set  other  events  in  motion.  If,  however,  the  chamber  is 

empty ,  the  TRANSIT  THROAT  logic  determines  whether  the  previous  throat  is 

empty.  If  the  previous  throat  contains  a  vessel,  it  is  known  that  the  lock 

has  been  committed  to  a  second  vessel  moving  sequentially  through  the  lock. 

If  the  previous  throat  is  empty,  the  lock  may  still  be  committed  to  a  second 

sequential  vessel.  The  logic  determines  whether  the  chamber  has  recycled 

since  the  current  vessel  left  it.  If  it  has,  it  must  be  awaiting  an  imminent 

arrival  from  the  previous  reach.  If  a  recycle  has  not  occurred,  the  logic 

now  determines  whether  the  next  queue  is  occupied.  If  this  queue  is  occupied, 

the  TRANSIT  THROAT  logic  arranges  for  the  first  vessel  in  the  queue  to  exit 

that  queue  and  begin  moving  into  the  chamber  (this  constitutes  an  alternating, 
2 

or  SOQA  queue  discipline).  However,  if  the  next  queue  is  empty,  the  logic 

checks  the  previous  queue  for  a  vessel  that  may  move  sequentially  through 

3 

the  lock  (this  would  constitute  a  FCFS  queue  discipline).  If  the  previous 
queue  is  empty  and  the  service  look-ahead  feature  of  NETSIM/SHIP  is  not  to 
be  used,  TRANSIT  THROAT's  work  is  finished.  The  lock  is  idle  until  the  next 
vessel  arrives.  If  the  service  look-ahead  feature  is  to  be  used,  the 
previous  reach  is  checked  for  an  imminent  arrival.  If  there  is  no  imminent 
arrival  in  the  previous  reach,  the  lock  remains  idle  until  its  next  arrival. 

If  there  is  an  approaching  vessel  In  the  previous  reach,  the  service  look¬ 
ahead  feature  then  checks  the  next  reach  for  an  imminent  arrival.  If  the 
next  reach  has  no  approaching  vessel,  the  TRANSIT  THROAT  logic  begins  to 


Serve  opposing  queues  alternatively. 
^Firet  come  first  served. 
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recycle  the  chamber  in  order  to  receive  the  vessel  from  the  previous  reach 
upon  its  arrival  However,  if  the  next  reach  does  contain  an  approaching 
vessel,  the  service  look-ahead  feature  determines  which  of  the  two  imminent 
arrivals  could  move  into  the  chamber  earlier.  The  lock  is  committed  to 
that  vessel  with  the  earlier  expected  chamber  tie-up  time,  recycling  the 
chamber  if  the  vessel  in  the  previous  reach  could  be  earlier. 

If  the  previous  queue  is  occupied,  and  NETSIM/SHIP's  service  look¬ 
ahead  feature  is  not  to  be  used,  the  TRANSIT  THROAT  logic  determines  whether 
the  chamber  is  about  to  begin  recycling  to  receive  the  vessel  currently 
waiting  in  the  previous  queue,  If  a  recycle  is  imminent,  the  first  vessel 
in  the  previous  queue  exits  that  queue  and  moves  into  the  previous  throat. 

If  no  recycle  is  about  to  occur,  it  is  determined  whether  the  chamber  is 
currently  recycling  If  a  recycle  is  occurring,  the  first  vessel  in  the 
previous  queue  enters  the  previous  throat.  If  no  recycle  is  currently 
occurring,  one  is  begun 

In  the  situation  where  the  previous  queue  is  occupied  and  the  model's 
service  look-ahead  feature  is  used,  the  next  reach  is  checked  for  an 
imminenc  arrival,  If  there  is  a  vessel  approaching  the  lock  from  the  next 
reach,  its  expected  chamber  tie-up  time  is  compared  with  that  of  the  first 
vessel  m  the  previous  queue  The  lock  is  committed  to  the  vessel  with  the 
earlier  expected  tie-up  time,  recycling  the  chamber  and  removing  the  first 
vessel  from  the  previous  queue  if  that  vessel  is  expected  to  be  first.  If 
there  is  no  vessel  approaching  the  lock  from  the  next  reach,  the  chamber  is 
recycled  to  receive  the  first  vessel  in  the  previous  queue. 
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e  EVENT  TO  BEGIN  CYCLE 

The  EVENT  TO  BEGIN  CYCLE,  like  the  EVENT  TO  TRANSIT  THROAT,  has  a 
dual  function,  as  illustrated  in  Figure  13-  A  chamber  cycle  can  be  an 
empty  cycle  (referred  to  as  a  recycle)  or  it  may  contain  a  vessel  (referred 
to  as  a  process).  For  the  recycle,  the  EVENT  TO  BEGIN  CYCLE  does  nothing 
more  than  schedule  the  end  of  the  recycle  at  some  randomly  determined 
future  time  The  logic  concerned  with  an  occupied  cycle,  i.e.  ,  a  process, 
is  more  complex 

If  the  next  queue  by  which  the  chamber  vessel  will  pass  is  occupied, 
the  BEGIN  CYCLE  logic  only  schedules  the  end  of  the  process  to  occur.  If, 
however,  this  queue  is  empty,  the  previous  queue  is  checked  to  determine 
whether  it  is  occuped  If  there  is  no  vessel  in  the  previous  queue,  the  end 
of  the  process  is  scheduled.  There  is  no  need  to  check  adjacent  reaches  at 
this  point  because  ocher  routines  within  the  lock  module  contain  the 
necessary  logic  to  cover  the  possible  situations.  If  the  previous  queue 
contains  a  vessel  and  the  service  look-ahead  feature  is  not  to  be  used,  the 
end  of  the  process  :s  scheduled  and  an  EVENT  TO  EXIT  QUEUE  is  scheduled  to 
remove  the  first  vessel  from  the  previous  queue.  If  the  service  look-ahead 
leature  is  used  and  discovers  chat  there  is  no  vessel  approaching  the  lock 
from  the  next  reach,  the  same  events  occur,  i.e.,  the  end  of  the  process  is 
scheduled  and  the  first  vessel  is  removed  from  the  previous  queue.  If  the 
next  reach  does  contain  an  imminent  arrival,  it  is  determined  whether  this 
arrival  could  be  expected  to  be  in  its  chamber  tie-up  position  before  the 
vessel  from  the  previous  queue  could  do  so-  The  lock  is  committed  to  the 
vessel  with  the  earlier  expected  arrival  time,  scheduling  an  EXIT  QUEUE  event 
.t  the  vessel  in  the  previous  queue  is  expected  to  be  earlier. 
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Figure  13  General  Logic  Flow  of  the  EVENT  TO  BEGIN  CYCLE 


f  EVENT  TO  END  CYCLE 

When  a  lock  chamber  has  completed  a  cycle,  there  are  basically  two 
sets  of  events  that  may  occur  Which  set  of  events  occurs  depends  on  the 
current  status  of  the  chamber,  i.e  ,  whether  the  chamber  contains  a 
vessel  or  whether  it  is  empty.  These  two  event  possibilities  are  illus¬ 
trated  in  Figure  14. 

If,  at  the  end  of  a  cycle,  there  is  a  vessel  inside  the  chamber,  the 
EVENT  TO  END  CYCLE  schedules  the  vessel  to  begin  moving  out  of  the  chamber 
to  a  point  in  its  exit  throat  where  the  vessel  just  clears  the  chamber 
gates =  No  other  action  is  necessary  since  the  lock  model's  "experienced 
lockmaster"  logic  mechanisms  are  associated  with  the  EVENT  TO  PASS  THROUGH 
GATES  CLEAR  POINT 

When  the  io^k  chamber  is  empty,  indicating  that  the  chamber  has 
recycled  to  receive  a  waiting,  or  an  approaching  vessel,  the  END  CYCLE 
logic  determineo  which  event  must  occur  next  in  order  to  begin  processing 
the  next  vessel.  First,  the  throat  which  is  currently  at  chamber  water 
level  is  checked  tor  a  waiting  vessel  li  there  is  a  vessel  waiting  in 
the  throat's  short-entry  position,  END  CYCLE  schedules  a  TRANSIT  THROAT 
event  to  occur  in  order  to  move  the  vessel  into  tie-up  position  in  the 
chamber  It  the  vessel  is  not  waiting  in  short-entry  position,  it  must 
already  be  scheduled  to  move  direct iy  into  the  chamber.  In  this  case,  no 
further  logic  is  required,  since  a  TRANSIT  THROAT  event  is  already 
scheduled  for  moving  Lhe  throat  vessel  into  the  chamber. 

When  the  lock  chamber  and  the  water-level  throat  are  empty,  the  END 
CYCLE  logic  determines  whether  the  water-level  queue  contains  a  vessel  which 
should  move  into  the  chamber  for  processing.  If  there  is  a  vessel  waiting 
in  queue,  an  EVENT  10  EXIT  QUEUE  is  scheduled  to  occur  immediately. 
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Figure  14.  General  Logic  Flow  of  the  EVENT  TO  END  CYCLE 
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However,  if  che  water-level  queue  is  empty,  no  further  logic  is  necessary 
because  the  NETS1M/SH1P  logic  design  is  such  that  the  only  remaining  possi¬ 
bility  is  that  of  an  imminent  arrival  from  the  adjacent  reach.  This 
situation  is  handled  in  che  ROUTINE  TO  ARRIVE  AT  LOCK,  so  that  END  CYCLE 
need  continue  no  iutther. 

g.  EVENT  TO  PASS  THROUGH  GATES  CLEAR  POINT 

A  major  pore  ion  of  the  lock  module’s  service  look-ahead  feature  is 
within  the  EVENT  TO  PASS  THROUGH  GaTES  CLEAR  POINT.  This  portion  of  the 
service  look-ahead  feature  simulates  the  decision  process  of  an  experienced 
rational  lockmaster  in  deciding  whether  to  recycle  the  empty  chamber  as 
soon  as  possible,  i  e. ,  as  soon  as  the  gates  are  clear,  or  to  leave  it 
open  as  it  is  The  lockmaster 's  first  consideration  is  the  possibility 
chat  a  vessel  is  waiting  in  the  previous  throat.  If  there  is  a  vessel 
waiting  there,  che  chamber:  begins  recycling  immediately,  while  the  current 
vessel  continues  ex.cmg  to  the  iock  clear  point.  If  the  previous  throat 
is  empt>  the  lockmaster  logic  checks  the  next  queue  for  a  vessel  which 
could  pcssible  move  into  the  chamber  under  a  SOQA  queue  discipline.  If  the 
next  queue  contains  a  vessel,  the  current  vessel  continues  moving  to  the 
.  lear  point,  at  which  time  the  queued  vessel  will  begin  moving  into  the 
chamber  li  .he  next  queue  is  empty,  the  previous  queue  is  checked.  If 
there  is  a  vessel  in  the  previous  queue  and  the  service  look-ahead  feature 
is  used,  the  next  reach  is  checked  for  an  imminent  arrival.  If  there  is 
no  vessel  approaching  the  lock  from  the  next  reach,  the  vessel  currently 
waiting  in  the  previous  queue  begins  moving  into  a  short-entry  position 
whiie  che  chamber  begins  an  empty  recycle.  The  same  sequence  of  events 
occurs  if  there  is  an  approaching  vessel  in  the  next  reach  which  is  not 
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expected  to  be  in  the  chamber  before  the  vessel  from  the  previous  queue 
could.  If,  however,  the  next-reach  vessel  Is  expected  to  be  in  the 
chamber  earlier  than  the  previous-queue  vessel,  the  current  vessel  simply 
continues  its  exit,  leaving  the  chamber  open  for  the  imminent  arrival. 

If  the  previous  queue  is  empty,  this  means  that  the  lock  is  idle,  or, 
at  least,  will  be  idle  as  soon  as  the  exiting  vessel  reaches  the  clear 
point  If  the  service  look-ahead  feature  is  not  used,  there  is  nothing  to 
be  done  except  to  complete  the  current  vessel's  exit.  Otherwise,  the 
previous  reach  is  checked.  If  there  is  no  imminent  arrival  in  the 
previous  reach,  nothing  is  done.  However,  if  the  previous  reach  does 
contain  an  approaching  vessel,  the  next  reach  is  checked.  If  the  next 
reach  is  revealed  to  be  empty,  the  chamber  begins  recycling  to  receive 
the  vessel  approaching  from  the  previous  reach.  If  the  next  reach  contains 
an  imminent  arrival,  and  it  is  expected  to  be  in  the  chamber  before  the 
vessel  from  the  previous  reach,  the  chamber  remains  open  as  it  is  to 
await  the  arrival.  If  the  previous-reach  vessel  is  expected  to  be  first 
into  the  chamber,  recycling  begins  immediately  to  recei”..  the  arrival 
(see  Figure  15). 

2  LAKE:  a  Link  Module 

The  LAKE  module,  in  comparison  with  the  LOCK  module,  is  very  simple. 

It  is  composed  of  two  routines:  the  ROUTINE  TO  SAIL  ACROSS  LAKE  and  the 
EVENT  TO  EXIT  LAKE.  The  function  of  the  former  is  to  receive  a  vessel 
upon  arrival  at  a  lake  and  to  schedule  the  vessel's  exit  from  the  lake, 
while  the  latter  serves  to  remove  a  vessel  from  a  lake  and  to  summon  the 
MOVEMENT  CONTROLLER  to  decide  the  vessel's  next  move.  Associated  with  each 


lake  in  a  simulated  network  is  an  array  of  internodal  distances  which  gives 
the  distance  between  any  two  nodes  located  on  a  lake. 
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3.  REACH:  a  Link  Module 

The  REACH  module  also  consists  of  two  routines.  The  ROUTINE  TO  SAIL 
THROUGH  REACH  schedules  a  vessel's  exit  from  a  reach.  This  scheduling  takes 
into  account  the  a  priori  condition  regarding  passing  in  the  reach.  The 
EVENT  TO  LEAVE  REACH  simply  removes  the  vessel  from  a  reach  and  invokes  the 
MOVEMENT  CONTROLLER  to  assign  the  vessel's  next  link. 

4.  PORT:  a  Node  Module 

The  port  module  is  unique  in  two  respects.  First,  it  is  the  only 
entity  in  NETSIM/'SHIP  which  can  originate  and  terminate  vessels.  Thus  it 
has  the  dual  role  of  both  being  a  node  and  a  facility.  Second,  the  port 
module  as  currently  implemented  in  the  model  is  extremely  primitive  in 
that  it  does  not  to  any  great  extent  simulate  the  comp,  ex  operations  of  a 
port  The  skeleton  frame  for  such  a  simulator  however,  is  present  in  the 
port  module. 

Two  routines,  the  R0UI1NE  TO  ENIER  PORT  and  the  EVENT  FOR  PORT  EXIT 
comprise  NETSIM/SHIP's  port  module.  The  former  receives  a  vessel  at  the 
port  and  subsequently,  either  schedules  its  departure  at  a  randomly 
determined  time  in  the  future,  or  destroys  it.  The  latter  option  is 
included  for  the  following  reasons  First,  it  may  be  desirable  to  perform 
a  simulation  with  a  fixed  number  of  vessel  trips  where  the  trips  are 
generated  by  an  external  program  such  as  TOWGEN.  In  this  case,  the  external 
program  acts  as  the  scheduler,  i-e  ,  the  external  program  determines  the 
schedules  of  the  fleet  in  advance  and  inputs  them  to  NETS1M/SHIP  so  that  each 
vessel  is  destroyed  upon  the  termination  of  its  journey.  Second,  it  may  be 
desirable  to  study  the  eftects  of  vessel  mterarrival  patterns  at  a  parti¬ 
cular  facility  such  as  a  lock  In  this  case,  the  interarrival  pattern  would 
be  determined  in  advance  and  vessels  would  need  to  be  destroyed  upon  trip 


termination  so  as  not  to  interfere  with  the  a  priori  interarrival  pattern. 

The  former  option,  that  is,  the  ability  of  a  port  to  schedule  departures, 
provides  a  framework  for  a  future  highly  elaborate  scheduling  mechanism. 

This  consideration  will  be  discussed  in  the  next  chapter. 

The  PORT  EXIT  routine  removes  the  vessel  from  the  port  and 
transfers  the  vessel's  control  to  the  TRAFFIC  CONTROL  module.  The  routine 
contains  two  features  which  render  it  useful  for  future  expansion.  First, 
it  allows  the  simulation  of  a  scheduling  mechanism  based  on  random  access 
of  ports.  That  is,  if  a  vessel  has  no  predefined  itinerary,  its  next  port 
is  determined  randomly  from  a  user  supplied  frequency  distribution  of  trips 
to  every  other  port  in  the  system.  Thus,  in  the  case  of  a  two  port  system, 
the  probability  of  a  trip  from  one  port  to  the  other  is  exactly  equal  to 
1  since  the  origin  from  one  port  implies  a  destination  at  the  other.  If 
there  are  more  than  two  ports,  however,  the  number  of  possible  destinations 
for  any  given  origin  port  Is  greater  than  one,  hence,  a  frequency  distri¬ 
bution  of  trips  would  be  needed.  The  random  access  schedule  is,  of  course, 
primitive,  and  can  be  replaced  by  a  more  sophisticated  mechanism.  On  the 
other  hand,  if  a  vessel  has  a  predefined  itinerary,  the  random  access 
scheduler  is  bypassed  and  the  vessel's  next  port  of  call  is  selected  from 
its  itinerary. 

The  PORT  EXIT  routine  also  allows  the  simulation  of  season  closing. 
Before  scheduling  a  vessel  for  another  port,  the  PORT  EXIT  routine  determines 
whether  the  simulated  shipping  season  has  ended.  If  it  has,  the  vessel, 
instead  of  being  rescheduled,  is  placed  into  winter  berth  at  its  current 
port  The  simulation  ends  when  arl  vessels  have  entered  winter  berth. 


5.  VESSEL:  A  System  Entity 

The  vessel  is  the  reference  point  for  all  the  events  during  a 
NETSIM/SHIP  simulation.  It  is  the  movement  of  vessels,  rather  than  the 
operations  of  the  network  facilities,  which  is  recorded  during  a 
simulation.  This  section  describes  the  attributes  of  a  NETSIM/SHIP 
vessel  and  the  sets  in  which  a  vessel  may  be  filed  as  it  transits 
network  links. 

The  entity  vessel  has  an  attribute,  ID  VESSEL,  which  is  its 
identification  number.  The  only  restrictions  on  the  vessel  entity  are 
that  the  ID  VESSEL  be  no  more  than  four  digits  and  that  each  vessel  have 
a  unique  identification  number  (this  establishes  a  maximum  fleet  size  of 
9999.  The  four-digit  requirement  can  be  altered,  if  necessary,  by 
changing  the  formats  of  NETS IM/ SHIP'S  write  statements  (refer  to  the 
Appendix).  VESSEL'S  second  attribute  is  one  giving  its  OVERALL  LENGTH. 

This  attribute  is  used  in  NETSIM/SHIP's  ALTERNATIVE  SELECTOR  routine  to 
ascertain  that  each  lock  in  an  alternative  route  is  able  to  process  a 
vessel  of  that  length.  It  is  also  used  to  affect  a  vessel's  link  transit 
time.  VESSEL'S  CARGO  TYPE  attribute  describes  the  cargo  carried  by  a 
vessel  and  can  be  used  by  an  expanded  scheduler  logic  to  determine  a 
vessel's  next  port  by  matching  the  vessel's  cargo  with  a  port's  cargo¬ 
handling  capabilities.  This  is  discussed  more  fully  in  Chapter  IV  under 
Future  Extensions.  VESSEL'S  next  four  attributes,  PREVIOUS  NODE,  CURRENT 
NODE,  NEXT  NODE,  and  DESTINATION,  comprise  a  vessel's  map  attributes.  These 
are  used,  in  conjunction  with  network  map  information,  by  the  traffic  control 
module  in  determining  a  vessel's  current  location  and  the  next  network 
facility  through  which  the  vessel  must  transit  in  order  to  reach  its 
destination.  A  vessel's  PREVIOUS  NODE,  CURRENT  NODE,  and  NEXT  NODE  change 
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as  the  vessel  moves  from  link  to  link  through  a  network,  while  a  vessel 
receives  a  new  DESTINATION  only  when  it  has  entered,  and  is  about  to  exit, 
its  current  DESTINATION.  Giving  a  vessel  its  new  DESTINATION  is  the  job 
of  NETSIM/SHIP's  rescheduling  logic  VESSEL’S  next  two  attributes, 

SELECTED  BRANCH  and  NODES  LEFT  IN  BRANCH,  are  closely  related  to  a  vessel's 
map  attributes.  SELECTED  BRANCH  is  used  by  the  ALTERNATIVE  SELECTOR  to 
determine  which,  if  any,  branch  of  a  set  of  parallel  routes  a  vessel  is 
transiting.  NODES  LEFT  IN  BRANCH  tells  the  ALTERNATIVE  SELECTOR  where  a 
vessel  is  located  within  a  route  which  is  parallel  to  other  routes.  Finally, 
VESSEL  has  an  attribute,  TIM  ARRIVAL,  which  gives  the  time  at  which  a  vessel 
arrives  at  a  particular  link  This  is  used,  along  with  the  time  at  which 
a  vessel  exits  from  the  link,  to  determine  the  time  required  by  the  vessel 
to  transit  the  link. 

As  a  vessel  moves  through  a  network,  it  is  filed  into  various  sets  which 
represent  the  different  links  being  simulated.  For  example,  a  vessel 
moving  through  a  lock  might  first  enter  a  queue,  then  move  through  a  throat 
into  a  chamber,  then  through  an  exit  throat  past  another  queue  and  out  of 
the  lock.  These  lock  sections  are  represented  in  NETSIM/SHIP  by  the 
following  five  sets,  respectively:  1  QUEUE,  1  THROAT,  CHAMBER,  2  THROAT, 
and  2  QUEUE.  The  lock  transit  example  can  now  be  explained  as  a  series  of 
set  filings  and  removals  An  arriving  vessel  might  be  filed  into  the 
1  QUEUE  set  of  a  lock  until  traffic  conditions  at  the  lock  are  appropriate 
for  the  vessel  to  begin  being  processed  through  the  lock.  At  such  time, 
the  vessel  is  removed  from  the  1  QUEUE  set  and  filed  into  the  1  THROAT  set 
while  the  time  required  to  transit  the  entrance  throat  elapses.  At  the  end 
of  the  transit  throat  time  period,  the  vessel  is  removed  from  the  1  THROAT 
set  and  filed  into  the  CHAMBER  set  of  the  lock.  After  the  time  necessary 


56 


for  a  lock's  chamber  to  cycle,  the  vessel  is  removed  from  the  CHAMBER  set 
and  filed  into  the  2  THROAT  set,  the  equivalent  of  the  vessel’s  exit 
throat.  At  the  end  of  this  exit  throat  transit  time,  the  vessel  passes 
the  lock's  second  queue,  represented  by  the  2  QUEUE  set,  which  may  contain 
vessels  waiting  to  transit  the  lock  in  the  opposite  direction.  These  sets, 
and  their  relationships  to  other  NETSIM/SHIP  sets,  are  illustrated  in 
Figure  16. 

A  vessel's  transit  through  NETSIM/ SHIP's  other  links,  the  REACH  and 
LAKE,  as  well  as  the  PORT,  are  also  represented  by  a  series  of  set  filings 
and  removals.  The  NETSIM/SHIP  REACH  is  composed  of  two  sets,  1  DIRECTION 
and  2  DIRECTION,  representing  the  two  directions  of  travel  through  a  re«.ch. 
As  a  vessel  enters  a  reach,  it  is  filed  into  either  the  1  DIRECTION  set  or 
the  2  DIRECTION  set,  depending  upon  its  direction  of  transit.  NETSIM/SHIP 's 
LAKE  simulator  consists  of  but  one  set,  ON  LAKE  TRAFFIC,  since  direction  of 
transit  is  not  considered  to  attect  lake  transit  time.  There  are  two  sets, 
DOCK  and  WINTER  BERTH,  associated  with  the  PORT  model.  DOCK  is  the  set  into 
which  a  vessel  is  filed  during  the  time  period  simulating  a  port  stay. 

WINTER  BERTH  is  the  set  which  recives  those  vessels  that  are  in  port  at  the 
end  of  a  simulated  season 

D  Support  Routines 

The  support  module  came  about  as  a  result  of  an  attempt  to  reduce 
duplication  within  the  NETSIM/SHIP  logic  structure.  There  are  several  areas 
within  NETSIM/SHIP  where  identical,  or  similar,  logic  is  used  to  perform 
certain  repetitious  tasks  Each  task  is  therefore  assigned  a  routine,  and 
and  the  support  module  is  composed  of  five  such  routines. 
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1.  ROUTINE  TO  SEARCH  TABLE  OF  NEXT  NODES 

Called  by  the  MOVEMENT  CONTROLLER  routine,  the  ROUTINE  TO  SEARCH 
TABLE  OF  NEXT  NODES  receives,  as  arguments  from  the  MOVEMENT  CONTROLLER, 
a  vessel's  CURRENT  NODE  and  its  DESTINATION.  The  routine  searches  down 
the  vertical  axis  of  the  TABLE  OF  NEXT  NODES  until  it  locates  a  node 
identification  number  which  matches  that  of  the  vessel's  CURRENT  NODE. 

It  then  searches  across  the  horizontal  axis  until  it  finds  a  match  for 
the  vessel's  DESTINATION.  The  indices  identifying  the  row  and  column, 
respectively,  of  the  TABLE  OF  NEXT  NODES  where  the  matches  occur  are 
returned  to  the  MOVEMENT  CONTROLLER  as  arguments. 

2.  ROUTINE  TO  REFERENCE  FACILITIES  TABLE 

The  MOVEMENT  CONTROLLER  calls  upon  the  ROUTINE  TO  REFERENCE 
FACILITIES  TABLE  to  determine  the  identification  number  for  a  vessel's 
next  facility.  The  routine  first  searches  down  the  vertical  axis  of  the 
FACILITIES  ID  TABLE  until  it  finds  a  node  identification  number  which 
matches  that  of  the  vessel's  CURRENT  NODE.  The  horizontal  axis  is  then 
searched  for  a  match  to  the  vessel's  NEXT  NODE.  The  indices  identified 
by  these  matches  locate,  within  the  body  of  the  table,  the  identification 
number  of  the  link  which  connects  the  vessel's  CURRENT  NODE  with  its  NEXT 
NODE-  This  identification  number  is  returned  to  the  MOVEMENT  CONTROLLER 
as  the  vessel's  next  facility - 

3.  ROUTINE  FOR  STOCHASTIC  TIME  CALCULATIONS 

During  simulation,  whenever  a  random  time  is  needed  for  any  of  the 
NETSIM/SHIP  time  blocks,  the  ROUTINE  FOR  STOCHASTIC  TIME  CALCULATIONS  is 
called  to  provide  the  random  time  element.  Altogether,  NETSIM/SHIP  includes 
twelve  different  time  blocks,  which  requires  that  the  ROUTINE  FOR  STOCHASTIC 
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TIME  CALCULATIONS  be  given  a  code  by  the  calling  routine  to  identify  the 
proper  time  block  to  be  used.  The  routine,  after  identifying  the  proper  time 
block,  determines  whether  the  distribution  function  has  been  provided 
empirically  by  the  user  or  whether  it  is  to  be  one  of  the  eleven  SIMSCRIPT- 
supplied  theoretical  distributions.  If  the  distribution  is  an  empirical 
one,  the  routine  samples  from  it  using  SIMSCRIPT's  random  variable  mechanisms. 
On  the  other  hand,  if  the  distribution  is  a  SIMSCRIPT  theoretical  function, 
a  separate  section  of  the  ROUTINE  FOR  STOCHASTIC  TIME  CALCULATIONS  is  called 
to  perform  the  sampling-  Finally,  the  adjusted  time  value  is  returned  by 
the  ROUTINE  FOR  STOCHASTIC  TIME  CALCULATIONS  to  the  calling  routine 

There  are  eleven  statistical  distribution  functions  supplied  by  the 
SIMSCRIPT  system  (see  Kiviac,  page  314).  Each  of  these  eleven  functions  is 
available  to  a  NETSIM/SHIP  user  for  describing  any  of  the  time  blocks  within 
the  model  (refer  to  the  Appendix).  This  availability  is  made  possible 
through  the  logic  to  calculate  theoretical  random  time  which  calls  a  particular 
SIMSCRIPT  function  and  returns  tc  the  calling  routine  the  random  value 
generated  by  the  function 

4.  ROUTINE  TO  USE  ATTRIBUTES  TO  ADJUST  TIME 

Designed  to  permit  linx  transit  times  to  reflect  the  effects  of 
attributes  of  the  system  entities  involved,  the  ROUTINE  TO  USE  ATTRIBUTES 
TO  ADJUST  TIME  is,  m  the  present  implementation,  a  demonstration  of  the 
potential  for,  rather  than  an  actual,  use  of  the  time-affecting  attributes. 

5-  ROUTINE  TO  QUERY  INIRALAKE  DISTANCES  TABLE 

The  final  routine  in  the  support  module  is  used  by  the  lake  module  and 
by  the  ALTERNATIVE  SELECTOR  to  include  the  effects  of  distance  In  the  compu¬ 
tation  of  a  lake  transit  time  The  routine  searches  through  the  INTRALAKE 
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DISTANCES  TABLE  (refer  to  Figure  17)  until  it  locates  the  proper  lake, 
current  node,  and  next  node.  These  three  indices  provide  the  distance  from 
the  current  node  to  the  next  node.  This  distance  is  returned  to  the  calling 
routine . 


62 


Figure  17,  INTRALAKE. DISTANCES. TABLE:  Array  Storage  for  Lakes’ 
Internodal  Distances 
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IV.  RESEARCH  POSSIBILITIES  AND  FUTURE  EXTENSIONS 

The  increasing  levels  of  traffic  experienced  by  the  Great  Lakes-St. 
Lawrence  River  Seaway  have  brought  to  forefront  the  need  for  a  careful 
assessment  of  the  waterway's  ability  to  meet  the  demands  placed  upon  them 
within  the  foreseeable  future.  Because  of  the  extremely  high  cost  and  long 
life  of  structural  improvements ,  the  need  for  accurate  and  detailed  research 
into  structural,  as  well  as  non-st ructural,  alternative  improvements  is 
easily  recognizable.  The  current  implementation  of  NETSIM/SHIP,  as 
described  in  this  report,  provides  a  powerful  tool  for  use  in  conducting 
the  needed  research. 

The  potential  applications  for  NETSIM/SHIP  involve  primarily  investi¬ 
gations  into  the  impact  of  both  structural  and  non-structural  alternative 
improvements.  NETSIM/SHIP  permits  the  user  to  consider  the  effects  upon 
the  system  of  various  fleet  characteristics,  varying  traffic  levels,  new 
and/or  improved  facilities,  changing  commodity  flows,  different  facility 
locations,  ship  scheduling  procedures,  dock  strikes,  and  changes  in  the 
length  of  the  shipping  season 

To  conduct  research  into  some  of  the  areas  mentioned  requires  more 
sophistication  in  the  model  than  is  currently  available  in  NETSIM/SHIP. 
However,  the  development  of  NETSIM/SHIP  is  a  continuous  undertaking  and, 
at  the  time  of  this  writing,  efforts  are  being  made  to  extend  the  model 
into  the  proper  levels  to  enable  a  full,  system-wide  investigation  of  the 
problem  areas.  The  extensions  to  be  implemented  during  the  earlier  develop¬ 
mental  phases  include  a  port  model  which  determines  a  vessel's  turn-around 
time  as  a  function  of  the  characteristics  of  the  vessel  and  of  the  port, 
a  rescheduler  model  which  selects  a  vessel's  next  port  as  a  function  of  the 
vessel's  cargo-carrying  capabilities  and  the  ports'  cargo-availability 


64 


characteristics,  and  a  post-simulation  processor  to  prepare  NETSIM/SHIP's 
two  output  data  bases  for  statistical  analysis.  Later  phases  of  NETSIM/ 
SHIP'S  development  could  include  an  elaborated  post-simulation  processor 
to  produce  graphical  displays  of  simulation  results,  an  expanded  reach 
model  to  explicitly  take  into  consideration  the  effects  of  reach  width, 
depth,  and  sinuosity,  an  additional  lock  model  for  explicitly  simulating 
the  operations  of  shallow-draft  locks,  and  a  capability  for  a  user  to 
conveniently  select,  through  input  parameters,  one  of  several  specific 
facility  models. 

With  the  implementation  of  the  suggested  extensions,  NETSIM/SHIP 
would  be  capable  of  supporting  research  with  a  system-wide  perspective  of 
the  effects  of  improved  port  facilities.  In  its  current  implementation, 
the  model  can  be  used  for  studying  alternative  lock  designs,  as  well  as 
alternative  canal  designs  for  developing  parallel  transit  routes.  Studies 
of  lock  capacities  under  varying  conditions  of  traffic  and  fleet  composition 
can  be  conducted.  An  investigation  of  the  implications  of  an  extended 
length  for  the  shipping  season  could  b°  carried  out  using  the  improved 
NETSIM/SHIP. 
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V.  SUMMARY 

The  model  described  in  this  report  is  an  extension  of  a  navigation 
systems  simulator  developed  by  the  Pennsylvania  Transportation  and  Traffic 
Safety  Center.  The  initial  model  (hereafter  referred  to  as  MCDD)  is 
described  by  Rea  and  Nowading  in  their  research  report,  Simulation  of 
Multiple  Channel  Deep  Draft  Navigation  Systems,  (1971).  The  authors 
describe  the  features  which,  if  implemented,  would  greatly  increase  the 
usefulness  of  the  model  as  a  research  tool. 

The  unique  feature  of  the  MCDD  is  its  capability  for  simulating 
concurrent,  two-way  traffic  movements  through  multiple  parallel  canals. 

This  capability  is  made  possible  by  the  use  of  a  unique  assignment  map 
technique.  The  assignment  map  feature  involves  the  generation  of  an 
experience  data  base  which  is  statistically  analyzed  to  derive  expected 
transit  time  functions.  Expecced  transit  times  are  computed  for  each 
alternative  canal  based  on  current  conditions  within  the  canal.  A  vessel 
is  assigned  to  the  canal  yielding  the  least  expected  transit  time. 

The  MCDD  model  includes  the  capability  for  simulating  locks  and  reaches. 
Its  lock  simulator  uses  eight  probability  distributions  to  simulate  time 
lapses  during  a  lock's  operations  Each  lock  is  allowed  to  have  a  distinct 
set  of  distributions  Queues  are  served  alternately  (a  SOQA  queue  discipline) 
until  there  exists  but  one  queue,  at  which  time  the  queue  discipline  is 
FCFS.  The  model  includes  a  recycle  "look-ahead"  feature,  which  recycles  an 
empty  chamber,  given  certain  conditions,  to  minimize  a  vessel's  delay.  The 
model's  reach  simulator  can  use  one  of  two  distributions  for  a  reach's  transit 
time  to  take  into  consideration  any  directional  differences  in  transit  times. 

A  no-passing  rule  is  maintained  in  all  reaches,  thus  allowing  an  entering 


vessel  to  catch,  or  fall  farther  behind,  an  immediately  preceding  vessel,  but 
not  to  get  ahead  of  it 
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The  logic  structures  providing  the  MCDD  model's  capabilities  are 
conceptually  modularized.  The  modular  framework  groups  closely  related 
logic  structures,  thereby  permitting  any  particular  module  to  be  altered 
with  a  minimal  amount  of  disturbance  to  the  other  modules.  The  model 
is  programmed  using  GPSS  (General  Purpose  Simulation  System)  ,  an  easily- 
learned,  problem-oriented,  discrete-event,  simulation  language. 

The  basic  justification  for  the  current  project  is  the  desire  for  a 
generalized  transportation  model  The  concepts  developed  during  the 
MCDD  model's  evolution  can  be  used  to  describe  any  network  system  com¬ 
prised  of  nodes  and  links.  However,  because  of  the  inefficiency  and 
extreme  physical  size  that  would  result  if  GPSS  were  used,  the  MCDD  model 
cannot  be  conveniently  expanded  to  simulate  any  arbitrary  transportation 
network.  Because  it  is  a  general-purpose,  multiple-level  (upper  levels 
are  designed  especially  for  discrete-event  simulation  applications) 
programming  language,  SIMSCRIPT  is  used  in  developing  the  extended, 
generalized  model  (hereafter  referred  to  by  the  acronym  NETSIM/SHIP, 

NETwork  SIMulator  applied  to  SHIP  movements) . 

NETSIM/SHIP  embodies  all  the  features  of  the  MCDD  model  described 
above,  as  well  as  many  modifications  and  extensions.  NETSIM/SHIP 
differentiates  between  directions  of  travel  by  sampling  from  distinct 
distributions,  each  of  which  can  be  empirical  or  theoretical  according 
to  the  user's  selection.  All  random  times  can  be  modified  to  include 
effects  of  the  system  entities  involved.  The  lock  model  contains  an 
"experienced  lockmaster"  simulator  which,  when  no  queues  exist,  inspects 
adjacent  reaches  for  imminent  arrivals  and  commits  the  lock  to  that  vessel 
with  the  earliest  expected  arrival  time,  recycling  the  chamber  if  necessary 
This  ability  is  referred  to  as  the  service  look-ahead  feature.  A  second 
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ability  of  the  "experienced  lockmaster"  simulator  is  referred  to  as  the 
recycle  look-ahead  feature.  Whenever  a  ship  arrives  at  an  idle  lock, 
NETSIM/SHIP  assumes  that  the  "experienced  lockmaster"  would  have  seen  the 
arriving  ship  and  would  have  committed  the  lock  to  it,  recycling  if 
necessary,  in  order  to  minimize  the  ship's  delay.  The  reach  simulator 
features  an  "on-off"  switch  for  the  passing  rule.  With  the  passing  rule 
switched  "on,"  an  arriving  ship  can  get  ahead  of  preceding  ships  in  the 
reach.  Each  reach  can  have  the  passing  rule  on  or  off,  as  the  user 
desires.  NETSIM/SHIP  also  features  a  realistic  shipping  season  simulation 
model.  Each  ship  can  begin  the  shipping  season  from  a  distinct  port  at 
an  individually  determined  time  At  season's  end  each  ship  is  placed  in 
winter  berth  at  a  port. 

NETSIM/SHIP  extends  the  MCDD  model  by  providing  a  lake  simulator 
and  a  port  simulator.  The  lake  simulator  is  somewhat  similar  to  the 
reach  simulator  in  that  a  ship  enters  at  one  node,  receives  a  random 
transit  time,  and  exists  at  another  node.  The  lake  transit  times  are 
determined  using  an  array  of  intralake  intemodal  distances  and  attributes 
of  the  lake  and  ship.  Direction  of  transit  has  no  effect.  Ship  passings 
are  always  allowed.  The  port  simulator  is  included  in  NETSIM/SHIP  pri¬ 
marily  as  a  demonstration  of  the  potential  of  such  a  model.  A  realistic 
simulation  model  of  port  activities  requires  considerable  research  and 
programming  The  current  port  simulator  does,  however,  provide  the  basic 
mechanisms  for  a  more  realistic  model.  The  port  accepts  a  ship  and 
determines  a  random  time  for  its  stay  in  port.  The  port  simulator  includes 
a  "season-ending"  feature  which  is  invoked  prior  to  a  ship's  exit  from  a 
port.  If,  when  a  ship  is  about  to  exit  a  port,  the  shipping  season  has 
ended,  the  ship  is  placed  into  winter  berth  at  that  port.  If  the  season 
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has  not  ended,  the  ship's  new  destination  port  is  obtained  from  the 
NETSIM/SHIP  "scheduler"  feature.  Each  ship,  when  it  enters  the  system, 
can  have  a  pre-assigned  itinerary.  The  scheduler  references  the  array 
of  ship  itineraries  and,  if  the  exiting  ship  is  listed  therein,  assigns 
the  ship  to  the  port  indicated  on  its  itinerary.  If  a  ship  has  no 
preassigned  itinerary,  the  scheduler  randomly  selects  the  ship's  next 
port  using  a  probability  distribution  of  available  ports.  The  scheduler 
feature  can  be  expanded  to  include  attributes  of  ports  and  the  ship  in 
selecting  a  ship's  next  port- 

The  logic  structures  of  NETSIM/SHIP,  like  those  of  the  MCDD  model, 
are  conceptually  modularized,  i.e,,  structures  of  similar  function  are 
grouped  together.  The  complete  logical  framework  is  segregated  into  the 
following  four  modules: 

1.  Initialization 

2.  Traffic  control 

3.  Support 

4.  Link 

The  logic  flow  of  the  NETSIM/SHIP  process  can  be  described  in  terms  of 
interactions  among  the  conceptual  modules. 

Prior  to  the  beginning  of  simulated  time,  the  initialization  module 
reads  in  parameters  and  system  entity  attributes,  sets  up  the  simulated 
system  and  schedules  each  ship  to  exit  its  designated  port  at  its 
designated  time.  The  port  module,  upon  each  ship  exit,  calls  the  traffic 
control  module  Using  NETSIM/SHIP's  dynamic  course  determination  feature, 
the  traffic  control  module  determines  each  ship's  next  link  (lock,  lake, 
or  reach)  and  calls  the  appropriate  logic  module.  When  a  ship  reaches  its 
next  node,  the  traffic  control  module  is  called  again.  The  node  reached 
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by  the  ship  may  be  its  destination  port  and,  if  it  is  so  determined  by  the 
traffic  control  module,  the  port  module  is  called  upon  to  receive  the  ship; 
otherwise,  the  traffic  control  module  determines  the  ship's  next  link  and 
calls  the  appropriate  module  -  This  cycle  of  interactions  among  the  modules 
continues  until  the  end  of  the  simulated  shipping  season.  The  support 
module  is  called  throughout  the  simulation  by  the  other  modules  for 
assistance  in  array  searching  and  random  time  generation. 

The  input  data  required  by  NETS1M/SHIP  are  divided  into  four  categories: 
(1)  parameters  needed  for  a  particular  run,  (2)  parameters  giving  the 
dimensions  (numbers  of  lakes,  locks,  vessels,  etc.)  of  the  simulated  system, 
(3)  attributes  of  the  system  entities,  and  (4)  arrays  describing  the  layout 
of  the  system.  The  output  data  supplied  by  NETSIM/SHIP  are  of  basically 
two  categories:  (1)  the  Experience  Data  liase  (EDB) ,  and  (2)  the  EVENT  LOG. 
The  EDB  contains  prior  canal  conditions  for  each  ship  arrival  and  subsequent 
ship  transit  times.  The  EDB  is  statistically  analyzed  to  derive  functions 
used  to  compute  expected  transit  times  during  a  simulation.  These  expected 
transit  time  functions  are  the  basis  for  NETSIM/SHIP 's  capability  for 
dynamically  determining  a  ship's  course  through  multiple  parallel  canals. 

The  EVENT  LOG  is  generated  during  a  simulation  run,  giving  data  that  describe 
each  event  occurrence  during  the  run.  The  LOG  is  statistically  analyzed  to 
determine  system  performance  relative  to  whatever  parameters  the  user  is 
interested  in. 

In  its  current  state  of  development,  NETSIM/SHIP  can  be  used  in  numerous 
research  projects  involving  simulation  of  deep  draft  waterways.  The  detailed 
lock  module  permits  lock  design  studies.  Studies  can  be  done  on  the  system 
effects  of  lock  designs  and  lock  location.  Alternate  canal  configurations 
can  be  investigated.  With  the  development  of  a  realistically  detailed  port 


module,  NETSIM/SHIP  would  be  capable  of  commodity  flow  studies,  studies 
on  the  Implications  of  port  design  and  commodity  handling  equipment  con¬ 
figurations,  and  the  .effects  of  ship  design  on  system  and  port  utili¬ 
zation,  as  well  as  many  other  projects  involving  port  system  simulation. 

A  refined  reach  module,  which  would  include  consideration  for  such  factors 
as  reach  width,  depth,  number  of  bends,  etc.,  would  increase  NETSIM/SHIP’s 
capabilities.  The  true  power  of  the  model,  however,  lies  in  the  conceptual 
framework  upon  which  NETSIM/SHIP  is  built.  The  conceptualization  of  the 
traffic  control  module  is  so  general  that  attributes  of  particular  traffic 
entities,  and  attributes  of  particular  nodes  and  links,  have  no  effect  on 
the  capabilities  of  NETSIM  as  a  network  simulator.  This  means  that,  with 
the  development  of  the  proper  simulator  modules,  NETSIM  can  be  used  for 
research  applications  involving,  for  example,  personal  rapid  transit  systems, 
mass  urban  transit  systems,  or  airport  design.  As  previously  stated,  if  a 
network  system  can  be  described  in  terms  of  nodes  and  links,  NETSIM  can 
be  used  to  simulate  it. 


71 


REFERENCES 

1.  Carroll,  Joseph  L. ,  and  Bronzini,  Michael  S.  ,  "Waterway  Systems  Simu¬ 
lation:  Volume  1 — Summary  Report,"  Vol.  I  of  a  series,  Report 
TTSC  7108,  Pennsylvania  Transportation  and  Traffic  Safety  Center, 

The  Pennsylvania  State  University,  University  Park,  Pennsylvania,  1971. 
2  Rea,  John  C. ,  and  Nowading,  David  C  Waterway  Systems  Simulation: 

Volume  V — Simulation  of  Multiple  Channel  Deep  Draft  Navigation 
Systems .  Report  TTSC  7112,  Pennsylvania  Transportation  and  Traffic 
Safety  Center,  The  Pennsylvania  State  University,  University  Park, 
Pennsylvania,  1971. 

3.  Carroll,  Joseph  L. ,  "Waterway  Lock  Simulation  Model,"  Papers,  Sixth 
Annual  Meeting,  Transportation  Research  Forum,  1965. 

4-  Hazard,  John  L  The  Great  Lakes-St  Lawrence  Transportation  System — 
Problems  and  Potential-  Upper  Great  Lakes  Regional  Commission, 
Washington,  D.C.,  1969. 

5=  The  St.  Lawrence  Seaway  Authority  and  St  Lawrence  Seaway  Development 
Corporation  Trafilc  Report  of  the  St.  Lawrence  Seaway,  1970 
Ottawa,  Canada:  Queen's  Printer,  1970. 

6  Bronzini,  Michael  S.  Waterway  Systems  Simulation:  Volume  II — TOWGEN: 

A  Tow  Generation  Model  for  Inland  Waterway  Simulation.  Report 
TTSC  7110,  Pennsylvania  Transportation  and  Traffic  Safety  Center, 

The  Pennsylvania  State  University,  University  Park,  Pennsylvania,  1971. 

7  Kiviat,  P  J.,  R.  Villanueva,  and  H,  M,  Markowitz,  The  SIMSCRIPT  II 

Programming  Language.  Prentice-Hall  Inc  ,  Englewood  Cliffs,  N.J.,  1968. 


72 


Appendix 


NETSIM/SHIP 
USER’S  MANUAL 


73 


Table  of  Contents 

A.  Introduction  ............ 

B.  Input  Data  Stream  ...  ...... 

1.  Run  Parameters  ........  . 

2.  System  Size  Parameters  . . . 

3.  System  Entity  Descriptors  ....... 

4.  Network  Configuration  Descriptors  .  .  . 

5.  Externally-Supplied  Fleet  Characteristics 

C.  Output  Data  Bases  ....  ........ 

1.  The  Experience  Data  Base  (EDB)  ..... 

2.  The  Simulation  Event  Log  (LOG)  . 

3.  Error  Messages  .  .  ........ 


Page 

74 

74 

75 

76 

77 
86 
88 
89 
89 
91 

101 


74 


A.  Introduction 

NETSIM/SHIP  is  a  general  network  simulation  model  capable  of  simulating 
concurrent,  bi-directional  traffic  through  multiple,  parallel  routes.  The 
model  is  programmed  in  SIMSCRIPT  11.5,  a  general-purpose  simulation  language. 
Because  of  the  highly  technical  nature  of  NETSIM/SHIP  the  user  is  assumed  to 
be  familiar  with  the  general  areas  of  research  (presently,  waterway  simu¬ 
lation)  in  which  the  model  is  being  applied.  In  addition,  the  user  should 
have  access  to  the  following  two  documents: 

1.  Kiviat,  P.  J.,  R.  Villanueva,  and  H.  M.  Markowitz.  The  SIMSCRIPT  II 

Programming  Language.  Prentice-Hall,  Inc.,  Englewood  Cliffs, 

N,  J. ,  1968. 

2.  Consolidated  Analysis  Centers,  Inc-  SIMSCRIPT  II. 5  User's  Manual. 

Consolidated  Analysis  Centers,  Inc.,  Los  Angeles,  Calif.,  1971. 

The  purpose  of  this  User's  Manual  is  to  provide  a  guide  by  which  a  user 
can  be  insured  of  properly  preparing  the  necessary  input  data  stream  for 
NETSIM/SHIP  and  of  properly  interpreting  the  output  data  bases.  The  manual 
is  divided  into  basically  two  sections.  The  first  section  describes,  in 
detail,  NETSIM/SHIP's  required  input  data  stream.  NETSIM/SHIP ' s  two  output 
data  bases,  as  well  as  its  error  messages,  are  covered  in  the  second  section. 

B  Input  Data  Stream 

Before  describing  the  actual  input  data  stream,  a  brief  mention  of 
SIMSCRIPT's  free-form  READ  statement  (Kiviat,  page  7)  is  in  order.  There 
are  only  two  restrictions  concerning  the  format  of  the  input  data  stream. 
First,  each  number  in  the  stream  must  be  separated  from  preceding  and 
succeeding  numbers  by  at  least  one  blank  (there  may  be  any  number  of  blanks 
above  one).  Second,  a  number  must  not  be  continued  from  one  card  to  the 
next  (a  number  terminates  at  the  end  of  a  card) .  Numbers  may  be  punched 
as  either  real  or  integer.  However,  if  a  real  number  has  a  fractional 
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part,  its  decimal  must  be  included.  Since  SIMSCR1PT  treats  input  data  as 
a  continuous  stream  of  numbers,  a  number's  particular  location  on  a  card  is 
not  considered,  as  long  as  it  is  properly  positioned  relative  to  the  other 
numbers  in  the  stream.  The  correct  relative  positions  for  the  input  data 
received  for  NETSIM/SHIP  are  described  in  the  remainder  of  this  section. 

The  data  required  by  NETSIM/SHIP  are  divided  into  the  following  four 
categories : 

1.  Run  Parameters 

2  System  Size  Parameters 

3.  System  Entity  Descriptors 

4.  System  Network  Descriptors 

Explanation  of  each  category,  along  with  specifications  for  each  datum, 
are  given  below. 


1.  Run  Parameters 

The  run  parameters  provide  NETSIM/SHIP  with  information  pertaining  to 
available  options. 

Datum  Description 

11  the  length  of  the  "season"  being  simulated  in  minutes. 

1-2  1,  if  the  run  generates  an  Experience  Data  Base  (EDB) 

0,  if  the  run  generates  a  simulation  event  LOG  (LOG) . 

13  1,  if  the  run  uses  NETSIM/SHIP 's  service  look-ahead 

feature  for  dynamic  queue  selection.  0,  if  the  service 
look-ahead  feature  is  not  used. 

1.4  1,  if  the  system  being  simulated  contains  one  or  more 

facilities  with  parallel  alternative  facilities.  0,  if 
the  system  has  no  parallel  facilities. 

the  device  number  for  the  output  unit  upon  which  NETSIM/ 
SHIP  writes  its  output  data  bases.  It  can  be  any  number 
between  1  and  15,  excluding  2,  3,  and  5.  This  number 
must  agree  with  the  number  given  on  the  Data  Definition 
(DD)  card  (for  IBM  OS/360  JCL) . 


1.  5 


Datum 


Description 
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1.6  the  device  number  for  the  input  unit  from  which  NETSIM/ 

SHIP  receives  the  necessary  external  data  for  generating 
system  arrivals. 

17  1,  if  vessels  are  to  enter  ports,  be  re-scheduled,  and 
continue  on  their  routes.  0,  if  vessels  are  to  be 
destroyed  upon  port  entry. 

18  1*  If  necessary  data  for  scheduling  system  arrivals  are 
to  be  supplied  exogenously  during  program  execution. 

0,  if  these  data  are  to  be  supplied  with  standard  input 
data  stream. 

2.  System  Size  Parameters 

The  size  parameters  determine  the  extent  of  the  system  being 
simulated,  and  provide  appropriate  amounts  of  memory  space  within  the 
computer.  Each  datum  must  be  an  integer  value,  with  its  maximum 
determined  by  the  capacity  of  the  equipment  (computer)  being  used. 

The  system,  in  NETS1M/SHIP,  is  defined  as  a  network  of  links  and 
nodes.  Every  facility  (lock,  reach,  lake,  etc.)  is  modeled  as  a  link. 
Every  link  must  be  bounded  on  either  side  by  a  node  which  delineates 
any  tw  links.  A  node  may  either  be  a  port  or  an  arbitrarily  defined 
link  delimiter.  Only  a  port  node  may  originate  and  terminate  vessel 
journeys  Non-port  nodes,  however,  act  as  decision  points  where 

a)  the  vessel  decides  whether  alternative  routes  exist. 

b)  the  vessel  determines  the  type  of  facility  that  must  be 
negotiated. 

Non-port  nodes  are  thus  useful  in  providing  the  vessel  with,  in  essence, 
a  map  of  its  journey. 

The  format  of  the  system  parameters  is  as  follows: 


Datum 

Description 

2  1 

the 

number 

of 

ports 

2  2 

the 

number 

of 

lakes 

2.3 


the  number  of  reaches 


Datum 


Description 
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2  4 

the 

number 

of 

2.5 

the 

number 

of 

2.6 

the 

number 

of 

the 

number 

of 

2.7 

the 

number 

of 

locks 

vessels  (set  equal  to  1,  if  datum  1.8  =  1). 

nodes  (includes  the  number  of  ports  plus  the 
non-port  nodes) . 

vessels  that  have  pre-assigned  itineraries. 


3  System  Entity  Descriptors 

The  system  entity  descriptors  are  composed  of  data  for  each  port, 
lake,  reach,  lock,  and  vessel  included  in  the  simulated  system.  The  data 
must  be  given  in  a  specific  order,  i.e.,  all  ports,  then  all  lakes,  then 
all  reaches,  then  all  locks,  and  then  all  vessels.  Within  this  arrangement, 
however,  order  is  not  critical  (e.g.,  it  does  not  matter  whether  the  data 
for  port  n  is  read  before  or  after  the  data  for  port  n-1,  as  long  as  both 
data  streams  are  composed  according  to  the  specifications  given  below,  and 
both  streams  precede  those  for  vessels). 

Datum  Description 

31  the  port  identification  number  (any  integer  from  1  to  9999). 

32  an  integer  (c-9999)  identifying  either  the  type  or  amount  of 
commodity  held  at  the  port.  The  datum  is  not  actually  used 
during  the  simulation  run,  but  is  included  to  demonstrate 
the  possibility  of  port  commodity  manipulation. 

3.3  a  Cumulative  Distribution  function  (CDF)  identifying  the 

probabilities  of -a  vessel's  transiting  to  any  other  port 
in  the  system  Because  the  datum  is  defined  by  NETSIM/SHIP 
as  a  Random  Step  Variable  (RSV,  refer  to  Kiviat,  page  316), 
it  must  be  followed  by  an  asterisk  (*) ,  e.g,,  0.1  1022  0.2 

1032  0  35  1042  0-55  1052  0.8  1062  1.0  1072  *. 

1,  if  the  CDF  describing  the  time-lapse  for  a  vessel's  stay 
in  port  is  one  of  the  SIMSCRIPT-supplied  theoretical  CDF's 
(see  Kiviat,  page  314)  0,  if  the  CDF  is  empirical  and  is 

included  as  part  cf  the  input  data  stream. 


3-4 
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Datum  Description 

35  If  datum  34  *  datum  o  3  is  composed  of  the  following 

items : 

(1)  identiti.at number  of  the  port 

(2)  an  integer  code  referring  to  the  selected 

SIMSCRxrl-o-pp^^ea  CDF  (refer  to  Table  1  below  and 
Kiviat ,  r-agc  0*-*, 

(3) ,  f4)  and  to.  agaments  for  the  SIMSCRIPT-suppiied 

CDF  as  desc;i cad  m  kiviat,  page  314.  If  the  CDF 
specifies  Jti.j  :*c  arguments,  item  (5)  must  still 
be  included  m  tnc  ..nput  stream  as  0  (zero) 

If  datum  3  4  -  u ,  a= : 3  5  is  the  empirical  CDF,  defined 
and  read  by  NEIa^M  aH.P  as  an  RSV  (refer  to  the  discussion 
on  RSV's  m  3  3  sc-ve,- 

Data  31  through  3-5  are  repeated  ea.h  port  in  the  simulated  system. 

3-6  the  lake  identify  .at :  jU  number  t,  1—9999)  . 

3.7  the  number  ci  n:des  vinc.uding  ports)  connected  to  the 

lake , 

3  8  1,  if  the  -s  «  inn.  within  a  set  of  parallel  links; 

0,  it  not 

0-9  if  the  CDF  ceo.£.o.fi6  .he  time-lapse  for  a  vessel's  lake 

transit  is  zu-  -i  cr.e  S.MSCRIPT-supplied  theoretical 
CDF's,  datum  o  y  .  =  1  tone/,  If  the  CDF  is  empirical  and 
is  included  as  r=.rc  _i  the  input  data  stream,  then  3  9 
is  0  (zsrw 

d-iO  if  datum  3-9  is  - „  datum  o  lO  is  composed  of  the 

following  i . vt  items* 

(i>  ident it  i . a  . .  ,n  r.umbe;  of  the  lake 
(2)  an  .ncegct  n-iu  c~de  referring  to  the  selected 
SiMSCRic I -supp ..td  CDF  prefer  to  Table  1  above) 

(o;  ,  (.4;,  at.d  t5;  arguments  for  the  SlMCRIPT-supplled 
CDF  os  dee.tiDed  j.u  Kiviat,  page  314,  If  the  CDF 
specities  .ruj  _w~  arguments,  item  (5)  must  be 
loCxUdcd  in  the  input  stream  as  0  (zero), 
li  datum  3  9  is  0,  uatum  o  10  is  the  empirical  CDF, 
defined  and  read  z.y  NEISIM/SHiP  as  a  RSV  (refer  to  the 
discussion  cn  RSv  r  .  .  3d  above) 

0  11  Datum  3  u  *s  .ptiv-na..  dependent  upon,  first,  whether 

the  run  is  EDB  c.  lOo  ano,  second,  whether  the  lake 
exists  as  a  paro-.o-  » .:k  it  Datum  1,2  is  0  (zero)  and 
Datum  3-8  .s  l  ,  Datum  3  ii  consists  of  the  follow¬ 

ing  9  items. 
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TABLE  i 

NETS  IM/' SHIP  Codes  for 
Statistical  Distribution  Functions 


Function 

NETSIM/SHIP  Code 

BETA.  F 

1 

BiNOMiAL.  F 

2 

ERLANG .  F 

3 

EXPONENTIAL.  F 

4 

GAMMA.  F 

5 

LOGNORMAL,  F 

6 

NORMAL,  F 

7 

POISSON  F 

8 

RANDI.  F 

9 

UNIFORM  F 

10 

WEIBULL  F 

11 

Datum 


Description 
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3.12 


Data  3. 

3.13 

3.14 

3.15 

3  16 

3.17 

3  18 

3.19 


(1)  identification  number  of  the  lake 

(2)  a  coefficient  to  be  used  to  weight  the  effect  upon 
expected  transit  time  of  the  number  of  vessels  on 
the  lake  when  the  vessel  makes  its  decision  as  to 
which  alternative  set  of  links  to  use 

(3)  a  coefficient  used  to  weight  the  effect  upon 
expected  transit  time  of  the  distance  from  the 
vessel's  entry  node  to  its  exit  node 

(4)  -  (9)  0  (these  provide  the  capability  for  additional 

factors  to  be  included  when,  and  if,  needed). 

Any  of  the  factors  can  be  deleted  by  setting  its  coefficient 
equal  to  0  (zero) . 

Datum  3.12  consists  of  an  Origin-Destination  (0-D)  table 
which  gives  the  distance  between  any  two  nodes  on  the  lake. 
The  table  is  read  row  by  row.  The  first  row  contains,  in 
its  first  column,  the  identification  number  of  the  lake. 
Columns  2  through  n  of  the  first  row  contain  the  identifi¬ 
cation  of  each  node  (including  ports)  on  the  lake.  There 
is  no  required  order  for  the  node  identification  numbers . 

The  first  column  of  rows  2  through  ii  contains  the  identifi¬ 
cation  number  of  each  of  the  n  nodes  on  the  lake.  Columns 
2  through  n^  of  rows  2  through  n  contain  individual  inter- 
nodal  distances 

6  through  3.12  are  repeated  for  each  lake  in  the  simulated  system. 

the  reach  identification  number  (1-9999). 

the  length  of  the  reach,  in  feet. 

1,  if  vessel  passings  are  allowed  within  the  reach, 

0,  if  passings  are  not  allowed. 

1,  if  the  reach  is  a  link  within  a  set  of  parallel  links; 

0 ,  if  not 

1,  if  the  CDF  describing  the  time-lapse  for  a  vessel's  reach 
transit  is  one  of  the  SIMSCRIPT-supplied  theoretical  CDF's. 
0,  if  the  CDF  is  empirical  and  is  included  as  part  of  the 
input  data  stream. 

the  identification  number  (1-9999)  of  the  reach's  upstream 
end-point  node. 

the  identification  number  (1-9999)  of  the  reach '9  down¬ 
stream  end-point  node. 
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Datum 

3.20 


3.21 


Description 

If  datum  3.17  is  1,  datum  3.20  is  composed  of  the  following 
six  items: 

(1)  identification  number  of  the  reach 

(2)  identification  number  of  the  upstream  end-point 
node  toward  which  a  vessel  sails  when  its  transit 
time  is  described  by  the  CDF 

(3)  an  integer  (1-11)  referring  to  the  selected 
SIMSCRIPT-supplied  CDF  (refer  to  Table  1  above) 

(4)  ,  (5),  and  (6)  arguments  for  the  SIMSCRIPT-supplied 

CDF  as  described  in  Kiviat,  page  314.  If  the  CDF 
specifies  only  two  arguments,  item  (6)  must  be 
included  in  the  data  input  stream  as  0  (zero) . 

Items  (1)  through  (6)  are  repeated  for  the  reach's 
downstream  end-point  node.  The  two  sets  of  six 
items  combine  to  provide  a  unique  CDF  for  each 
direction  of  traffic  flow. 

If  datum  3.17  is  0,  datum  3.20  consists  of  two  empirical 
CDF's,  one  for  each  direction  of  traffic  flow  in  the  reach. 

The  first  empirical  CDF  corresponds  to  3.18,  i.e.,  3.18  is 
the  identification  number  of  the  reach's  end-point  node 
toward  which  vessels  sail  when  the  first  CDF  is  used  to 
describe  their  transit  times.  The  second  CDF  must  correspond 
to  3.19.  Because  each  CDF  is  read  by  NETSIM/SHIP  as  a 
random  step  variable,  each  one  is  followed  by  an  asterisk  (*) . 

If  datum  1.2  is  0  (zero),  and  datum  3.16  is  1  (one),  datum 
3.21  is  composed  of  twenty  items,  ten  for  each  of  the  two 
traffic  flow  directions.  The  items  are  entered  into  the 
input  data  stream  as  follows: 

(1)  identification  number  of  the  reach 

(2)  identification  number  of  the  upstream  end-point  node 
toward  which  the  vessel  is  sailing  when  its  Expected 
Transit  Time  (ETT)  is  determined  by  the  coefficients 
given  in  items  (3)  through  (10)  below 

(3)  coefficients  used  to  weight  the  effect  upon  expected 
transit  time  of  the  number  of  vessels  sailing  in  the 
opposite  direction  within  the  reach 

(4)  coefficient  used  to  weight  the  effect  upon  expected 
transit  time  of  the  number  of  vessels  sailing  in  the 
same  direction  within  the  reach 

(5)  coefficient  used  to  weight  the  effect  upon  expected 
transit  time  of  the  square  of  the  number  of  vessels 
sailing  in  the  opposite  direction  within  the  reach 

(6)  coefficient  used  to  weight  the  effect  upon  expected 
transit  time  of  the  square  of  the  number  of  vessels 
sailing  in  the  same  direction  within  the  reach 


Datum 


Description 
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(7)  coefficient  used  to  weight  the  effect  upon  expected 
transit  time  of  the  log^  of  the  number  of  vessels 
sailing  in  the  opposite  direction  within  the  reach. 

(8)  coefficient  used  to  weight  the  effect  upon  expected 
transit  time  of  the  log  of  the  number  of  vessels 
sailing  in  the  same  direction  within  the  reach. 

(9)  coefficient  used  to  weight  the  effect  upon  expected 
transit  time  of  the  square  root  of  the  number  of 
vessels  sailing  in  the  opposite  direction  within 
the  reach 

(10)  coefficient  used  to  weight  the  effect  upon  expected 
transit  time  of  the  square  root  of  the  number  of 
vessels  sailing  in  the  same  direction  within  the 
reach 

Items  (1)  -  (10)  are  repeated  for  the  downstream  direction. 

If  datum  1.2  is  1  (one)  and/or  datum  3.16  is  0  (zero), 
datum  3.21  is  not  included  in  the  input  data  stream. 

Data  3.13  through  3.21  are  repeated  for  each  reach  in  the  simulated  system. 

3.22  identification  number  of  the  lock. 

3.23  the  identification  number  (1-9999)  of  the  lock's  upstream 
end-point  node. 

3.24  the  identification  number  of  the  lock's  downstream  end-point 
node. 

3.25  the  maximum  vessel  length,  in  feet,  that  can  be  processed 
by  the  lock 

3.26  a  code  representing  whether  the  lock  is  within  a  set  of 
parallel  links.  The  code  is  1  if  the  lock  is  in  a  set  of 
parallels,  0  if  it  is  not. 

Each  lock  has  associated  with  it  nine  different  CDF's  for  determining  the 
random  time  lapses  of  different  events.  Data  3.27  through  3.35  determine 
whether  each  of  the  nine  CDF's  is  a  theoretical  or  an  empirical  CDF.  If 
the  particular  CDF  is  a  SIMSCRIPT-supplied  theoretical  CDF,  its  datum  is 
1  (one).  If  the  CDF  is  empirical  and,  therefore,  supplied  with  the  input 


To  avoid  the  problem  which  arises  in  the  computation  of  the  log  of  zero 
NETSIM/SHIP  actually  adds  0.001  to  the  argument  before  the  logarithmic 
operation. 
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data  stream,  its  datum  is  0  (zero) .  Each  description  given  below  describes 
the  particular  time  block  connected  with  each  datum.  The  datum  is  either  1 
(one)  or  0  (zero),  as  described  above 


3.27 

3.28 

3.29 

3.30 

3.31 

3.32 

3.33 

3.34 


time  from  clear  point  to  tie-up  in  chamber,  from  a  moving 
start. 

time  from  clear  point  to  tie-up  in  chamber,  from  a  stationary 
start. 

time  from  just  outside  chamber  gates  to  tie-up  in  chamber. 

time  from  tie-up  in  chamber  to  point  where  vessel's  stern 
is  clear  of  chamber's  gates. 

time  from  point  where  vessel's  stem  is  clear  of  chamber's 
gates  to  clear  point. 

time  from  clear  point  to  position  just  outside  chamber 
gates,  from  moving  start. 

time  from  tie-up  in  queue  to  position  just  outside  chamber 
gates. 


time  required  by  chamber  for  processing. 

Data  3.36  through  3.44  below  are  composed  of  either  (1)  arguments  for 
a  SIMSCRIPT-supplied  theoretical  CDF,  or  (2)  the  values  for  an  empirically- 
determined  CDF.  Each  datum  consists  of  either  arguments  or  empirical 


values  depending  upon  whether  its  corresponding  datum  in  3.27  through  3.35 


is  1  (one) 

or  0  (zero) , 

respectively. 

3.36 

if  3.27 

is  1,  3  36  consists  of  the  following  six  items: 

(1) 

identification  number  of  the  lock 

(2) 

identification  number  of  the  lock's  upstream  end¬ 
point  node  toward  which  the  vessel  is  traveling 
when  its  transit  time  is  described  by  this  CDF 

(3) 

an  integer  (1-11)  referring  to  the  selected 
SIMSCRIPT-supplied  CDF  (refer  to  Table  1  above) 

(4), 

(5) ,  and  (6)  arguments  for  the  SIMSCRIPT-supplied 
CDF  as  described  in  Kiviat,  page  314.  If  the  CDF 
specifies  only  two  arguments,  item  (6)  must  be 
included  in  the  data  input  stream  as  0  (zero) . 

Items  (1)  through  (6)  are  repeated  for  the  lock's 
downstream  end-point  node. 


Datum 


Descr ipe ion 
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If  3.27  is  0,  3  36  consists  of  two  empirical  CDF's,  one 
for  each  direct.cn  of  traffic  flow  in  the  lock  The 
first  empirical  CDF  corresponds  to  3  24,  i-e  ,  3  24  is  the 
identif icaticn  numcet  ct  the  lock's  end-point  node  toward 
which  vessels  sail  when  the  first  CDF  is  used  to  describe 


their  transit  times. 
3.25.  Because  each 
step  variable,  each 

The  second  CDF  must  correspond  to 

CDF  is  read  by  NETSIM/SH1P  as  a  random 
:ne  is  followed  by  an  asterisk  (*) 

3.37 

same  as 

3  3b  cit^ep' 

that  3 

28 

replaces 

3.27 

3.38 

same  as 

3  36  except 

that  3 

.29 

replaces 

3.27. 

3-39 

same  as 

3  36  except 

that  3 

30 

replaces 

3.27. 

3.40 

same  as 

3  36  except 

that  3 

31 

replaces 

3-27. 

3.41 

same  as 

3  36  except 

that  3 

32 

replaces 

327 

3.42 

same  as 

3  3b  except 

that  3 

33 

replaces 

3.27. 

Datum  3.43 

(for  chamber 

recycle  time),  as  well 

as  3.44 

(for  chamber  process 

time),  differ  from  data  3  36  thr__>gh  3  ^2  in  that  their  times  are  not 
affected  by  direction  cf  transit  Therefore,  only  one  empirical  CDF,  or 


one  set  of  arguments,  is  gi-en  ict  ea.h  datum 

Des^r .ption 

If  3  34  is  * ,  o  40  consists  or  the  following  six  items: 

(1/  ident.iicaticn  number  of  the  lock 

(2)  1  (a  -ode  tor  tie  chamber  recycle  CDF) 

(3)  an  integer  (1-11/  referring  to  the  selected 
SIMSCRIFI-suppiced  CDF  (refer  to  Table  1  abcve) 

(4) ,  (5),  and  >6;  arguments  for  the  selected  S1MSCRIFT- 

supplied  CDF  as  des.tibed  in  Klviat,  page  3^.4  If 
the  CDF  specified  om>  two  arguments,  item  (b)  must 
sci*i  be  *n..iudea  in  the  data  input  stream  as  0  (zero) 

If  3  34  is  0,  3  j i  consists  of  the  empirical  JDF,  lollowed 

by  an  asterisk  (.*, 

If  3  35  is  i,  3  44  consists  of  the  following  six  items: 

(i;  identification  number  of  the  lock 

(2)  2  va  wcde  ter  the  chamber  process  CDF) 

(3)  an  integer  vi-11)  referring  to  the  selected 
SIMSCR1F I-suppl*ed  CDF  (reter  to  Table  1  above) 

(4) ,  (bj ,  and  (6)  arguments  for  the  selected  SIMSCRIPT- 

suppiied  CDF  as  described  in  Kiviat,  page  314  If 
the  CDF  specified  only  two  arguments,  item  (6)  must 
stllx  be  .n.iudad  n  the  data  input  stream  as  0  (zero) 

If  3  35  is  0,  j  44  , insist =  cf  the  empirical  CDF,  followed 

by  an  asterisk  i*, 


Datum 

3-43 


3  44 


Datum 


Dee-.:  1 1  ption 
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3.45  If  datum  1  2  is  0  (zero)  and  datum  3,26  is  1  (one),  datum 

3.45  is  composed  of  twenty  items,  ten  for  each  of  the  two 
traffic  flow  directions  The  items  are  entered  into  the 
input  data  stream  as  follows: 

(1)  identification  number  of  the  lock 

(2)  identification  number  of  the  upstream  end-point  node 
toward  which  the  vessel  is  sailing  when  its  Expected 
Transit  T_lme  (£11)  is  determined  by  the  coefficient 
given  in  items  (3)  through  (10)  below 

(3)  coefficient  used  to  weight  the  effects  of  the  size  of 
the  near  queue  upon  transit  time  through  the  lock 

(4)  coefficient  used  to  weight  the  effects  of  the  near 
throat's  status  upon  lock  transit  time  Throat 
status  can  be  one  of  the  following: 

(a)  0,  ii  throat  is  empty 

(b)  1,  ii  throat  contains  a  vessel  moving  in 
opposite  direction 

(c)  2,  if  throat  contains  a  vessel  moving  in  same 
direction 

(5)  coefficient  used  to  weight  the  effects  of  the  cham¬ 
ber's  status  upon  lock  transit  time-  Lock  status 
is  either  0,  1,  or  2  (chamber  is  either  empty,  has 
a  vessel  moving  in  opposite  direction,  or  has  a 
vessel  moving  in  same  direction,  respectively) 

(6)  coetij  .lent  used  to  weight  the  effects  of  the  far 
throat's  status  upon  lock  transit  time  Throat 
status  is  either  0,  1,  or  2  (refer  to  item  5  above) 

(7)  coefficient  used  to  weight  the  effects  of  tne  far 
queue's  siee  upen  lock  transit  time 

(8)  0 

(9)  0 

(10)  0 

Items  1  through  10  are  repeated  for  the  lock's  dewnstream 
end-pomt  r.oae. 

If  datum  1  2  ;s  not  0  (zero)  and  datum  3,26  is  net  1  (.one), 
datum  3  45  is  nit  .r.  eluded  in  the  input  data  stream. 

Data  3.23  through  3,45  are  repeated  for  each  lock  in  the  simulated  system 

If  datum  1.8  Is  1  (one),  data  3  46  through  3-53  are  omitted  frem  the  input 

data  stream  and  data  for  the  fleet  of  vessels  are  supplied,  during  execution 

externally  from  the  input  device  given  in  datum  1.6-  Otherwise,  if  datum 

1-8  Is  0  (zero),  the  fleet  data  consists  of  the  following: 

Datum  Description 

3.46  identification  number  of  the  vessel  (1-9999) 


3.47 


overall  length  ct  the  vessel,  in  feet. 


Datum 


Description 
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3.48  on  Integer  code  (1-9999)  representing  either  the  type  or 
quantity  of  commodity  being  carried  by  the  veasel. 

3.49  identification  of  the  port  from  which  the  vessel  la  to 
depart  at  the  beginning  of  the  simulated  aeaaon. 

3.50  0,  if  the  vessel  has  no  pre-determlned  itinerary  of  ports 
to  visit; 

1,  if  the  vessel  has  one  or  more  predetermined  ports  to 
visit. 

3.51  the  time  (in  minutes)  after  the  beginning  of  the  simu¬ 
lated  season  when  the  vessel  leaves  tha  port  given  in  3.49. 

3.52  If  3.50  is  1  (one),  3.52  is  the  number  of  ports  that  are 
predetermined  for  the  vessel  to  visit.  If  3.50  is  0, 

3.52  is  not  included  in  the  input  data  stream. 

3.53  If  3.50  is  0  (zero),  3.53  is  omitted. 

If  3.50  is  1  (one),  3.53  consists  of  the  following: 

(1)  identification  number  of  tha  veasel 

(2)  identification  number  of  the  first  predetermined 
port  to  visit 

(3)  identification  number  of  the  second  predetermined 
port  to  visit 


*  s 

(n+1)  identification  number  of  tha  nth  predetermined 
port  to  visit  (n  is  given  in  3.52). 

Data  3.46  through  3.53  are  repeated  for  each  vassal  in  tha  simulated  eystem. 


4.  Network  Configuration  Descriptors 

The  fourth  and  final  sactlon  of  tha  input  data  stream  is  composed 
of  the  following  four  tablasi 

(1)  TABLE  07  NEXT  NODES 

(2)  FACILITIES  ID  TABLE 

(3)  7ABALLEL  FACILITIES  TABLE 

(4)  ALTERNATIVE  WIDE  COEFFICIENTS 


They  are  entered  into  the  Input  deta  stream  as  described  below: 


Datum 


DcrCtipnon 
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4  1  TABLE  OF  NEXI  NODE.-,  ieaion  1  Section  1  is  an  Ongin- 

Destinati.cn  w-D;  mate  ex  its  first  row  contains  port 
identifies!. on  n„mrers  .every  port  must  be  included;  the 
first  row  cannot  have  identification  numbers  for  non-port 
nodes;  Its  fees'-  .c:.,mn  contains  the  identification  num¬ 
ber  of  avcij  n.de  m  ct.e  system  (including  non-port  nodes 
as  well  as  po<t  nodes;.  The  order  in  which  the  identifi¬ 
cation  combats  arc  entered  does  not  matter.  Each  row, 
second  chi . ugr.  tun  :o±omnc,  contains  identification  numbers 
ct  the  nodes  .  wn..h  u  vessel  must  next  transit  in  going 
from  ns  .ur:ct,  ..-,ac  ut>  c.lumn  one)  to  its  destination 
(.in  row  one  A  zero  .s  entered  in  the  row  1,  column  1 
position 

4,2  TABLE  Of  NEXI  NODES,  Se_ti..n  2  The  first  row  and  first 

column  of  the  s e. .  rid  section  must  be  identical  to  those 
of  the  tirsc  se:t.on  The  body  of  the  table  contains 
ident; iiv.at .or.  nemcare  of  sets  of  parallel  links  whenever 
a  set  ex. its  oeewean  a  node  and  a  destination  When  no 
set  ot  pata.:ei  jinn.-  exists,  enter  a  value  of  eero 

4-3  FACILITIES  ID  IABLE  ..ntains  identification  numbers  for 

every  linn.  tc  ween  every  two  nodes  in  the  system  The 
first  row  odd  iir«c  toiumn  both  contain  identification 
numbers  for  ea.n  node  -.ports  and  non-port  nodes;  in  the 
system  Ihe  .rue:  oi  :b=u  identification  numbers  is 
unimportant  .  iirane  through  n  of  rows  two  through 

n  contain  the  a-ru  . :  .  :=>t  ion  numbers  of  the  link  Detween 
any  twj  rasps  .  ce  .od.:ss  A  zero  is  entered  in  rhe 
row  1,  toicm:.  -  r..sici.r» 


4  4  Nambe.:  or  ow-  ;  rAfn._ cEL  EaCILIIIES  TABLE  Optional 

Omi r  if  d-.  um  .  >  -  :-.k 

4,5  PARALLEL  tAvuL.  J Optional  Omit  if  datum  1  4 

is  zero  Ire  tec.-.  -  ;cod  by  rows  (a  row  is  not  a  card 


A  row  contain*  a.'.,  n-  .  :.i .  unation  tor  any  single  alter¬ 
native,  Ea _r.  to-*  m.  .':i.ain  the  following  four  items, 
in  proper  .tie  : 

ti;  idee  u  .■  .mo ct  or  the  set  of  parallel 

\2)  the  n_mcet  :i  alternatives  within  the  set, 

:  e  ,  r.-w  j.a.0  .tu.oas  does  a  vessel  have? 

(3;  the  a.' -.  '"a  .  a  v,i'hin  each  set  through  which  all 
ctctii.  :  c  .  oru.t  during  an  EDB  run  The  value 
g./efi  Cc.c  rcnds  co  the  position  within  a  set 

: n  »r.  -  h  r. c  cj.  ernai.ve  is  listed  It  the  aiter- 
r.a>: :  .  e  *r  h  s  .  .eted  nrst  in  the  set  is  tc  be 
u-ed,  h;  .*  1;  if  the  alternative  which  is 

: . .  <  =o  r  .  a  a  the  set  is  to  be  used,  the  value 

.Sc  --  .  £.  tr  tb;s  even  for  an  EVENT  LOG  run 

(4.  The  :  .mb  r  ..i  rudes  included  in  the  alternative 

E,e:„>  ru  A  p=  ailel  facilities  must  begin  and  end 
with  3  o.de,  o:.d  must  have  one  node  separat.ng  each 
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Datum  Description 

pair  of  adjacent  links  within  the  alternative.  The 
total  number  or  these  nodes  (ports  included)  is 
given  here 

The  remainder  ot  each  row  is  determined  solely  by  the 
particular  alternative  being  described.  Item  number  five 
in  each  row  is  the  identification  number  of  the  alter¬ 
native's  upstream  end  node.  The  sixth  item  is  the 
identification  number  of  the  link  between  that  end  node 
and  the  next  node  m  the  alternative.  The  items  continue 
in  this  manner  until  the  alternative  is  completely 
described  in  terms  of  node,  link,  node,  link,  node,  etc. 

4.6  Alternative-wide  coefficients  for  expected  transit  time 

functions  (Optional  Omit  if  1.2.  =  1  and/or  1.4.  =  0.) 
There  ate  six  items  for  each  row  in  the  PARALLEL  FACILITIES 
TABLE: 

(1)  idenLiticat t on  number  of  the  set  of  parallel 
facilities 

(2)  identification  number  of  the  alternative's  upstream 
end  node  trom  which  these  coefficients  apply  (this 
gives  consideration  to  directional  effects) 

(3)  coefficient  to  weight  the  effect  upon  a  vessel's 
transit  time  through  the  alternative  of  the  length 
of  the  vessel 

(4)  coEffi. ient  1 1  weight  the  effect  upon  a  vessel's 
transit  time  through  the  alternative  of  the  previous 
vessel's  expected  ttansit  time 

(5)  coefficient  to  weight  the  effect  upon  a  vessel's 
transit  time  through  the  alternative  of  the  total 
number  ot  vessels  m  transit  through  the  alternative, 
regardless  or  direction 

(6)  constant  fci  expected  alternative  transit  time 
lijr. .. ti.i  it  none,  set  to  zero. 

The  six  items  aie  -speared,  with  item  number  2  being  the 
downstream  end  p.ini  node  for  the  alternative 


5-  Externally-Supplied  Fleet  Chaia_terist ics  (Optional:  Supply  only  if 
datum  1-8  is  1  (one; 

When  vessel  arrivals  into  the  simulated  system  are  to  be  triggered  from 
an  external  source,  the  following  nine  irems  are  provided  the  input  device 
given  in  1.6  for  each  vessel  arc*,  val- 
Datum  Description 

5-1  the  event  name,  (ORT  EXIT 

5,2  time  of  arrival  (must  be  given  as  a  real  number;  not  integer) . 
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Datum 

Description 

5.3 

vessel  identification  number 

(1-9999) . 

5.4 

overall  length  of  vessel  (in 

feet) . 

5.5 

commodity  code  (1-9999) . 

5.6 

identification  number  of  port 
initially  enter  system. 

from  which  vessel  is  to 

5.  7 

a  code  signifying  whether  the 
itinerary  (1,  if  itinerary,  0 

vessel  has  a  pre-determined 
,  if  no  itinerary) . 

5.8 

nunber  of  ports  on  itinerary. 
5.7  is  0. 

Optional.  Omit  if  Datum 

5.9 

itinerary.  Optional.  Vessel 
n  port  identification  numbers 
to  3.53). 

identification  number  and 
.  Omit  if  5.7  is  0  (refer 

5.10 

asterisk  (*) 

C.  Output  Data  Bases 

NETSIM/SHIP  produces  as  output  the  following  two  data  bases: 

(1)  the  Experience  Data  Base  (edb) 

(2)  the  Simulation  Event  LOG 

The  basic  difference  between  the  two  bases  involves  the  model's  assignment 
decision  rule.  The  EDB  is  analyzed  statistically  to  produce  coefficients 
that  are  used  in  expected  transit  time  functions,  during  a  subsequent 
simulation  run.  These  functions  are  used  to  make  the  channel  choice 
assignment  decision. 

1„  The  ExPeriencs  Data  Ease  (EDB) 

The  EDB  consists  basically  of  2  parts:  the  first  gives  prior  conditions 
existing  within  an  alternative  at  the  point  in  time  when  a  vessel's  assign¬ 
ment  decision  is  to  be  made,  while  the  second  gives  subsequent  arrival  and 
exit  times  for  the  vessel's  transit  through  each  link  within  the  chosen 


alternative. 


The  EDB  has  four  different  kinds  of  records,  each  of  which  is 
distinguished  below.  The  first  six  items  of  each  of  the  four  records 
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are  identical.  These  six  items  are  as  follows: 


Item 

Format 

Description 

1 

11 

Reference  code;  1  indicates  that  data  are  prior 
conditions,  2  indicates  that  data  are  subsequent 
arrival  and  exit  times. 

2 

13 

Number  of  nodes  remaining  in  the  alternative. 

3 

11 

Facility  type  code:  1  =  lock,  2  »  reach,  3  =  lake, 
4  =  port. 

4 

14 

Facility  identification  number. 

5 

14 

Vessel  identification  number. 

6 

14 

Overall  length  of  vessel. 

When  the  reference  code  is  1,  indicating  data  on  prior  conditions, 
there  are  three  possibilities  for  the  remaining  items  of  the  record, 
depending  upon  the  types  of  facilities  within  the  alternative.  These 
three  possibilities  are  as  follows: 

For  Facility  Type  Code  =  1  (indicating  a  lock) : 


Item  Format 

7  14 

8  II 


9  II 


10  II 


Description 
Number  of  vessels  in  near  queue. 

0,  if  there  is  no  vessel  in  near  throat. 

1,  if  there  is  a  vessel  in  near  throat  moving  in 
opposite  direction. 

2,  if  there  is  a  vessel  in  near  throat  moving  in 
same  direction. 

0,  if  there  is  no  vessel  in  chamber. 

1,  if  there  is  a  vessel  in  chamber  moving  in 
opposite  direction, 

2,  if  there  is  a  vessel  in  chamber  moving  in  same 
direction. 

0,  if  there  is  no  vessel  in  far  throat. 

1,  if  there  is  a  vessel  in  far  throat  moving  in 
opposite  direction. 

2,  if  there  is  a  vessel  in  far  throat  moving  in 
same  direction. 
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Item  Format  Description 

11  14  Number  of  vessels  in  far  queue. 

For  Facility  Type  Code  =  2  (indicating  a  reach): 

Item  Format  Description 

7  14  Number  of  vessels  in  reach  that  are  moving  in 

opposite  direction, 

8  14  Number  of  vessels  in  reach  that  are  moving  in 

same  direction. 

For  Facility  Type  Code  =  3  (indicating  a  lake): 

Item  Format  Description 

7  14  Number  of  vessels  in  transit  on  lake. 

When  the  reference  code  is  2,  indicating  data  on  subsequent  link 
arrival  and  exit  times,  each  record  has  the  same  data  items.  The  first 
six  items  of  each  record  are  as  discussed  above.  The  remaining  items 
are  as  follows: 

Item  Format  Description 

7  17  Arrival  time, 

8  D(7,0)  Exit  time. 

2,  The  Simulation  Event  LOG 

During  a  simulation  run.,  a  record  of  every  -rve'  f  that  occurs  is 
kept  in  the  EVENT  LOG.  Each  record  contains  the  wing  nine  items: 

Item  Format  Description 

1  14  Vessel  identification  number. 

2  14  Vessel  length,  in  feet. 

3  14  Identification  number  of  vessel's  current  node. 


4 


14 


Identification  number  of  vessel's  next  node- 


Format 


D(7 ,0) 


Description 

Facility-type  code 

1  -  lock 

2  -  reach 

3  -  lake 

4  -  port 

Facility  identification  number. 

Event  code. 

Current  time , 

Number  of  vessels  in  near  queue  (if  relevant). 


Item  number  7,  the  event  code,  is  interpreted  according  to  a  four¬ 
digit  code.  These  codes,  along  with  their  interpretations,  are  given  below. 

Event  Codes 

1001  Vessel  is  at  chamber  gates  ready  to  enter,  but  the  water  level  is 

not  quite  correct.  Hence,  the  vessel  experiences  a  delay.  The 
eighth  parameter  (current  time)  given  in  the  event  log  is 
actually  the  length  of  this  delay. 

Decision-triggering  event:  lock  arrival  (1000) 

Resultant  action:  enter  near  queue  (1100) 

1100  Near  queue,  near  throat,  chamber  are  empty.  Water  level  at  the 
moment  is  correct;  but  chamber  is  recycling  to  the  other  side, 

1101  Near  queue  is  not  empty. 

1102  Near  queue  is  empty.  Near  throat  is  not  empty. 

1103  Near  queue  and  near  throat  are  empty.  Chamber  contains  a  vessel 
sailing  toward  arrival  vessel, 

1104  Near  queue  and  near  throat  are  empty.  Chamber  contains  a  vessel 
sailing  in  same  direction  as  arrival  vessel.  Far  queue  is  not 
empty. 

1105  Near  queue  and  near  throat  are  empty;  chamber  is  empty;  water 
level  is  not  okay;  far  throat  is  empty;  far  queue  is  not  empty. 

1106  Near  queue  and  near  throat  are  empty;  chamber  is  empty;  water 
level  is  not  okay;  fa i  throat  contains  a  vessel  sailing  in  same 
direction  as  arrival  vessel;  far  queue  is  not  empty. 
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1107 

1108 

1109 

1110 

mi 

1112 

1113 

1114 

1115 

1116 

1117 


Near  queue  and  neat  threat  ate  empty;  chamber  Is  empty;  water 
level  is  not  okay;  fat  throat  contains  a  vessel  sailing 
toward  arrival  vessel 

Near  queue  and  near  throat  are  empty;  chamber  contains  a 
vessel  sailing  in  same  direction  as  arrival  vessel;  far  queue 
is  empty;  service  look-ahead  feature  is  used;  far  reach  con¬ 
tains  a  vessel  which  can  sail  into  chamber  before  arrival 
vessel;  reach  vessel  use3  MOVING. TTT  and  arrival  vessel  uses 
SHORT. TTI  for  comparison 

Same  as  1108  above  except  that  arrival  vessel  uses  MOVING ,TTT. 

Same  as  1108  above  except  that  reach  vessel  uses  STATIONARY, 
TTT. 

Same  as  1108  above  except  that  reach  vessel  uses  STATIONARY, 
TTT  and  arrival  vessel  uses  MOVING. ITT. 

Near  queue  and  near  throat  are  empty;  chamber  is  empty  and  is 
not  now  scheduled  for  recycling;  water  level  is  not  okay;  far 
throat  contains  a  vessel  sailing  in  same  direction  as  arrival 
vessel;  service  xock-ahead  feature  is  used;  chamber  has  not 
been  free  long  enough  to  complete  recycling  before  arrival 
could  be  in  chamber;  far  reach  contains  a  vessel  which  can 
sail  into  chamber  hero  re  arrival;  reach  vessel  uses 
STATIONARY , TTI  and  arrival  vessel  uses  SHORT , TTT  for  compari¬ 
son,, 

Same  as  1112  above  except  that  arrival  uses  MOVING. TTI- 

Same  as  1112  above  except  chat  reach  vessel  uses  MOVING  TTT , 

Same  as  lilz  above  ax-epr  that  reach  vessel  uses  MOVING  TTI 

and  arrival  vessel  uses  MOVING, TTT. 

Near  queue  and  near  cr. r.at  are  empty;  chamber  is  empty  and  is 
not  now  scheduled  for  recycling;  water  level  is  not  okay;  far 
throat  is  empty;  sex  rice  iccx-ahead  feature  is  used;  chamber 
has  not  been  free  -eng  enough  to  have  now  recycled;  chamber 
has  not  beeen  free  long  enough  to  complete  recycling  before 
arrival  vessel  coued  enter  chamber;  far  reach  contains  a 
vessel  which  can  sail  -ntr  chamber  before  arrival  vessel; 
teach  vessel  uses  MOVING  III  and  arrival  vessel  uses  SHORT, TTT, 

Same  as  1116  above  except  that  chamber  has  been  free  long 
encugh  to  complece  recycling  before  arrival  could  enter  cham¬ 
ber,  so  that  arrive,  vessel  uses  MOVING, ITT 


11x8 


Same  as  1116  above  except  that  chamber  has  been  free  long 
enough  to  ha.e  now  recycled,  so  that  arrival  vessel  uses 
MOVING  TTT, 
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Decision-triggering  event:  lc_k  arrival  (1000) 

Resultant  action:  move  to  short-entry  position  (1200) 

1201  Near  queue  and  near  throat  are  empty;  chamber  contains  a  vessel 
sailing  in  same  direction  as  arrival  vessel;  far  queue  is 
empty;  service  lock-ahead  feature  is  not  used;  chamber  is  now 
recycling  but  is  not  able  to  recycle  before  vessel  would  enter 
chamber  using  MOVING. ITT . 

1202  Near  queue,  near  threat,  chamber  and  far  queue  are  empty; 
service  look-ahead  feature  is  not  used;  chamber  is  recycling 
but  will  not  complete  recycle  before  arrival  could  move  into 
clamber, 

1203  Near  queue,  near  throat,  chamber  and  far  queue  are  empty; 
service  look-ahead  feature  is  not  used;  chamber  is  not  now 
recycling;  chamber  is  now  scheduled  to  recycle,  but  recycling 
would  not  be  completed  before  arrival  vessel  could  move  into 
chamber, 

1204  Near  queue,  near  throat,  chamber,  and  far  queue  are  empty; 
service  and  look-ahead  feature  Is  not  used;  chamber  is  not 
now  cycling  nor  is  it  now  scheduled  for  recycling;  chamber 
has  not  been  free  long  enough  to  have  completed  recycling 
before  arrival  vessel  could  move  Into  chamber. 

1205  Near  queue,  near  throat,  and  far  queue  are  empty;  chamber 
contains  a  vessel  moving  in  same  direction  as  arrival  vessel; 
service  lock-ahead  feature  is  used;  next  reach  Is  empty; 
chamber  would  not  be  able  to  complete  process  and  recycle 
before  vessel  could  mote  into  chamber. 

1206  Near  queue,  neat  throat,  chamber,  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  is  empty; 
chamber  is  now  scheduled  for  recycling,  but  it  will  not  be 
completed  befote  arrival  vessel  could  move  into  chamber, 

1207  Near  queue,  neat  throat,  chamber,  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  is  empty; 
chamber  is  not  now  scheduled  for  recycle,  nor  is  it  now 
recycling,  chamber  has  not  been  free  long  enough  to  have 
completed  recycling  betore  arrival  vessel  could  move  into 
chamber. 

Near  queue,  near  threat,  chamber,  and  far  queue  are  empty, 
service  look-ahead  featuie  is  used;  next  reach  is  empty; 
chamber  is  now  recycling,  but  will  not  complete  recycle 
before  arrival  vessel  could  move  into  chamber. 


1208 
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Near  queue,  near  chroar,  and  far  queue  are  empty;  chamber 
contains  a  vessel  moving  m  same  direction  as  arrival  vessel; 
service  look-ahead  feature  is  used;  next  reach  contains  a 
vessel  sailing  toward  arrival  vessel;  vessel  from  next  reach 
will  arrive  at  clear  point  after  chamber  vessel  (therefore 
uses  MOVING. TIT) ;  chamber  cannot  complete  processing  and 
recycle  before  arrival  could  have  moved  into  chamber  (there¬ 
fore  uses  SHORT. ITT);  vessel  from  next  reach  cannot  be  in 
chamber  before  arrival  vessel. 

Near  queue,  near  throat,  and  far  queue  are  empty;  chamber  con¬ 
tains  a  vessel  moving  in  same  direction  as  arrival  vessel; 
service  look-ahead  feature  1b  used;  next  reach  contains  a 
vessel  sailing  toward  arrival  vessel;  reach  vessel  will 
arive  at  clear  point  beiore  chamber  vessel  (therefore  using 
STATIONARY. TTT) ;  chamber  cannot  complete  processing  and 
recycle  before  arrival  could  have  moved  into  chamber  (there¬ 
fore  uses  SHORT. IT!) ;  reach  vessel  cannot  be  in  chamber 
before  arrival  vessel. 

Near  queue,  near  throat,  chamber,  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  contains  a 
vessel  sailing  toward  arrival;  chamber  is  now  recycling,  but 
will  not  finish  before  arrival  could  have  moved  into  chamber. 

Same  as  1211  except  that  chaniber  is  not  now  recycling;  chamber 
has  been  schedu.ed  tor  recycling,  but  will  not  complete 
recycle  before  arrival  vessel  could  have  moved  into  chamber. 

Near  queue,  near  threat,  chamber,  and  far  queue  are  empty; 
service  look-ahead  feature  is  used;  next  reach  contains  a 
vessel  sailing  toward  arrival  vessel;  chamber  is  not  now 
scheduled  tor  recycling  nor  is  it  now  recycling;  far  throat 
contains  a  vessel  sailing  in  same  direction  as  arrival  vessel; 
reach  vessel  will  arrive  at  clear  point  befora  throat  vessel 
(therefore  reach  vessel  uses  STATIONARY. TTT) ;  chamber  has  not 
been  free  long  enough  to  have  recycled  before  arrival  vessel 
could  have  moved  into  chamber  (therefore  arrival  vessel  uses 
SHORT. ITT;;  :  t. »  n  vessa.  annot  be  in  chamber  before  arrival 
vessel. 


Same  as  1214  except  that  reach  vessel  will  not  arrive  at  clear 
point  before  throat  vessel  (therefore  reach  vessel  uses 
MOVING. TT1) . 

Near  queue,  near  throat,  chamber,  far  throat,  and  far  queue 
are  empty;  service  look-ahead  feature  is  used,  nsxt  rsech 
contains  a  vassal  sailing  toward  arrival  vassal;  chamber  is 
not  now  recycling  nor  is  It  now  scheduled  to  recycle;  chamber 
has  not  been  free  long  enough  to  have  now  recycled;  chamber 
has  not  been  free  long  enough  to  have  recyclsd  befora  arrival 
could  be  in  chamber  (so  arrival  uses  SHORT. TXT);  reach  vessel 
cannot  be  in  chamber  before  arrival  vessel. 
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Decision-triggering  event :  *:c'k  arrival  (a.  GO) 

Resultant  action:  m.vc.  di'r«c."Iy  In'  :  hamber  *1300) 

I3G1  Near  queue  ana  near  :r.r.a  a:e  empty;  chamber  contains  a 

vessel  sailing  in  same  direction  as  arrival  vessel;  far  q^eue 
is  empty;  service  1 : .a- ahead  feature  is  not  used;  chamber  is 
now  recycling  and  wiii  omplete  cycle  before  arrival  could 
move  Into  chamber 

1302  Near  queue*  near  ;hr.a:,  .hamber,  ana  iar  queue  are  empt., ; 
fax  threat  is  either  entity  .r  contains  a  vessel  sailing  in 
same  direct*.!  as  arrival  vessel;  service  look-ahead  feature 
is  not  used;  chamber  is  now  recycling  and  wiii  complete  cycle 
before  arrival  vessel  c.cua  have  moved  Into  chamber 

1303  Same  as  l30e  except  t to i  chamber  is  net  now  rec/.icng,  .number 
is  now  scheduled  c.  recycle  and  will  ccmplete  recycling  beicte 
arrival  vessel  could  ha  e  m.  red  lore  -hamber 

1304  Same  as  1302  except  nat  .hamber  is  neither  new  recycling  not 
scheduled  for  recycling;  chamber  has  been  free  long  enough  to 
have  recycled  bsica  snivel  vessel  ::uld  have  entered  chamber 

1305  Near  queue,  rue:  :fc;  .■>*..  and  fa:  Hueue  are  empty;  chamber  con¬ 
tains  a  eeesel.  sai.cng  same  direction  as  arrival  vessel; 
service  *c .k-anead  teat vc  -a  used;  next  teach  has  no  vease* 
sailing  t.wa-a  acti-ai  vs»&ex;  hamber  Is  now  prc.esscng  and 
will  be  sole  to  cap: e: *  pre  e*s  and  recycle  bat  ore  ai rival 
could  move  ir."  namoec 

i j06  Near  queue;  naa:  chi -at,  chamber  and  far  queue  are  empty; 

lock-ahead  tea  cure  -  ~  used,  n^xt  rea.h  contains  no  vesse*. 
sailing  ccua.a  ease.;  chamber  is  now  scheduled  tc 

recycle  and  will  .mp..-  e  re-;  cling  before  arrival  vessel 
could  move  into  cr,  ~  icc c  ■ 

1307  Same  m  u06  except  cna:  m amber  is  neither  now  scheduled  t^ 
recycle  r»cr  is  new  ce  y..*&g;  hamber  has  been  free  long 
enough  t.  hv.e  .cap.* a  cad  recycling  before  arrival  vessel 
•nouid  k.c  it :  .  .'amber 

1308  Same  as  IjGo  ex.ep.  chat  chamber  is  not  now  scheduled  to  re¬ 
cycle  hut  is  new  •re_y;c.ing  ai<d  will  complete  recycling  before 
arrival  vessel  c. old  more  into  chamber 

1309  Near  queue,  and  ne»r  cnt^si  are  empty;  .hamber  contains  a 
cease,  sailing  in  same  drtic.i.a  as  arrival  vessel,  service 
lock-ahead  lea  are  *■>  ussa;  next  reach  contains  a  vessel  sail¬ 
ing  toward  urr*v a*  -ersei;  ica.h  vessel  arrives  at  clear  point 
after  chamber  vessel  ,-h  vessel  uses  MOVING.  HI);  chamber 
is  able  t.  ccmplete  r : o  -suing  and  recycle  before  arrival  ves¬ 
sel  :  uld  bate  ea'.vea  ihambe:  (a:  rival  vessel  uses  MOVING.  Ill) 
teach  vesse .  cancel  be  *n  hamber  before  arrival  vessel 
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Near  queue  and  r.iar  are  empty;  chamber  contains  a 

vessel  sailing  in  same  dice:  :icn  as  arrival  vessel;  sex  rice 
look-ahead  tea. are  is  used,  ntx.  reach  contains  a  vessel 
sailing  coward  arriv*.  v»sei;  reach  vessel  arrives  at  clear 
point  before  chamber  vessel  (:=a.h  vessel,  therefore,  uses 
STATIONARY  III, •  ,  name r i  is  sc.e  to  complete  processing  and 
recycle  before  3t ii.».  v^sss.  . . aid  have  entered  oh ameer 
(arrival  vessel,  the ce tore,  uses  MOVING. TIT);  reach  vessel 
cannot  De  in  chamber  Deters  arrival  vessel - 

Neat  queue,  :.»■*:  .hr-ao,  neuuoex  and  fat  queue  ate  empty; 
service  2c ok- ahead  feature  is  -sad;  next  reach  c.ntains  a 
vessel  eail.ng  ;.*aud  at: iva.,  chamber  is  now  recycling  and 
will  rompuett  ,;.ic  bef-re  arrival  vessel  could  have  moved 
into  chamber 


Near  queue,  a&ar  :r.- chamber  and  far  queue  are  empty; 
service  lock- ahead  ic.»:ure  .1  used;  next  reach  contains  a 
vessel  sailing  t-ws.  c  at  : .  ;ai ;  chamber  is  not  new  recycling, 
but  is  now  scheduled  ; recycling  and  will  complete  recycle 
before  arrival  vessel  ruu.d  move  into  chamber  - 

Near  queue-  near  one .a  . hamoa: ,  and  tar  queue  are  empty; 

far  threat  con  rams  a  srse.  sailing  in  same  direction  as 
ax r  Lva*  oesse. ;  servi  .c  ..:K~ahead  feature  is  used,  next  reach 
contains  a  -essci  is.**  .ward  arrival  vesse.;  .hambex  is 
net  new  li.y.l.ng,  n..  .>  c  now  scheduled  for  recycling, 
reach  vesse.  art.*-*  a  ..ear  point  before  throat  vessel 
(tea: to  vessel.,  thexei .  ..see  S1AI10NARY-11I; ;  chamber  has 
been  free  long  en. .gi  . o  have  recycled  before  arrival  vesse. 
could  hare  entered  r.ambot  \axciva..  vessel,  therefore,  uses 
MOVING  - III)  ;  reacr.  v«»«ei  lafm.:  be  in  chamber  before  arrival 


Same  as  .tr*u  ex-epo  nai  tea  n  -cioi.  dees  net  arrive  at  ..ee: 
p.tni  betotc  oorcst  vesse.  '_ea  h  vessel,  therefore,  uses 
STATi'ONARt.  ITT  , 

Near  qve..s,  neax  tnxvac,  .r.amcc.. ,  car  ohroat,  and  ra.  queue 
are  empty;  service  .cck-sheac  » = »rux s  Is  used;  next  reach 
contains  a  vessel  sailing  tuws-d  arrival  vessel,  chamber  has 
not  been  free  long  encugr.  tu  hare  new  recycled,  but  it  has 
been  free  long  enough  r.a.e  ..mp.eted  recycling  before 
ax  rival  vessel  ucula  have  sneered  .hamber;  reach  vessel  :anrict 
be  In  chamber  beicxe  ax :Lvai  vessel 

Near  queue,  neat  threat,  hambe',  iar  threat,  and  far  queue 
are  empty;  stnlce  xv.K~s.heaa  feature  is  used;  next  reach 
contains  a  vessel  Sa..v:.g  t.wotd  arrival  vessel;  chamber  has 
been  f:ee  long  i-xcugh  .  i,  .o  u  w  recycled;  reath  vsoaei  cannot 
be  in  chamber  b .  .  j.  •  xvai  essel. 

Near  queue,  near  chroa.,  and  chamber  axe  empty;  water  lever,  is 
okay-  Service  io.k  ahead  feature  is  used- 
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Decision-triggering  event,  excc  queue  (2000) 

Resultant  action:  move  into  member  (2100) 

2101  Chamber  is  empty  Water  level  is  okay. 

2102  Chamber  is  empty  Water  level  is  not  okay. 

Chamber  is  now  recycling  and  will  complete  cycle  before  vessel 
could  move  into  chamber. 

2103  Chamber  is  empty.  Water  .evel  is  not  okay.  Chamber  is  r.cc 

now  recycling.  Chamber  is  now  scheduled  to  begin  recycling 
and  will  complete  recycling  before  vessel  could  move  into 
chamber. 

Decision-triggering  event:  exit  queue  (2000) 

Resultant  action:  move  into  .-hort-encry  position  (2200) 

2201  Chamber  is  n.t  empry, 

2202  Chamber  is  empty  Water  level  is  not  okay.  Chamber  is  now 

recycling  but  will  n.t  cmpiete  cycle  before  vessel  cculd 
move  into  chamber 

a203  Chamber  is  empty  warer  level  is  not  okay.  Chamber  is  net 

now  recycling.  Chamber  Is  now  scheduled  to  begin  recycling 
but  will  net  comp. era  recycling  before  vessel  could  move  into 
chamber. 

Decision-triggering  event-  m;.t  „  on.rc  entry  position  (3000) 

3x01  Vessel  arviree  at  ar  r-e... try  position. 

Decision-triggering  avent;  translc  threat  (4000) 
ixCx  Vessel  enters  -hamber 

4x02  Vessel  exits  t.  clearance  point- 

Decision-triggering  event;  era  eye  *e  (6000) 

Resultant  action:  move  to  gates- clear  point  (6100) 

6101  Chamber  is  not  empty 

Decision-triggering  event:  end  cy-le  (6000) 

Resultant  action:  move  item  shore-entry  position  into  chamber  (6200) 


6x01 


Chamber  reryexed  empty  Ihtoat  to  which  gates  have  just 
opened  contains  a  vessex. 
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Decision-triggering  event,  end  cycle  (6000) 

Resultant  action:  chamber  remains  open  (6300) 

6301  Chamber  recycled  empty.  Throat  and  queue  to  which  gates  have 

just  opened  are  both  empty.  Since  there  is  no  vessel  in  the 
immediate  vicinity,  the  vessel  characteristics  in  the  event 
log  record  are  artificially  given  the  values  9999. 

Decision-triggering  event:  end  cycle  (6000) 

Resultant  action:  chamber  remains  open  (6400) 

6401  Chamber  recycled  empty.  Throat  to  which  gates  have  just 

opened  contains  a  vessel  moving  into  chamber,  i.e„,  it  is 
not  waiting  in  short-entry  position. 

Decision-triggering  event:  pass  through  gates  clear  point  (7000) 

Resultant  action:  chamber  vessel  exits  to  clearance  point  (7100) 

7101  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  is 
empty.  Queue  in  back  is  not  empty.  Service  look-ahead 
feature  is  used  Next  reach  contains  a  vessel  sailing 
toward  lock  which  could  move  into  chamber  before  queued  vessel 
could. 

7102  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  is  not 
empty . 

7103  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  and 
queue  in  back  are  both  empty.  Service  look-ahead  feature  is 
used.  Previous  reach  and  next  reach  both  contain  vessels 
sailing  toward  rock-  Vessel  from  next  reach  can  move  into 
chamber  before  vessel  from  previous  reach  could. 

7104  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  and 
queue  in  back  are  borh  empty.  Service  look-ahead  feature  is 
used.  Previous  reach  does  not  contain  a  vessel  sailing  toward 
lock. 

7105  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  and 
queue  in  back  are  both  empty.  Service  look-ahead  feature  is 
not  used. 

Decision-triggering  event,  pass  through  gates  clear  point  (7000) 

Resultant  action:  chamber  begins  recycle  when  gates  are  cleared. 

Chamber  vessel  exits  to  clearance  point  (7200) 


1 

) 


7201 


Throat  behind  chamber  vessel  is  not  empty. 
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7203  Throat  behind  chamoei  vessel  is  empty.  Queue  in  front  and 
queue  in  back  ate  b:ch  emp-.y  Service  look-ahead  feature  is 
used.  Previous  r e a _ r.  and  next  reach  both  contain  vessels 
sailing  toward  l.ex  vessel  from  next  reach  cannot  move  into 
chamber  before  vessel  rr:m  previous  reach  could. 

7204  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  and 
queue  in  back  are  both  empty.  Service  look-ahead  feature  is 
used.  Previous  reach  contains  a  vessel  sailing  toward  icck 
Next  reach  dees  not  con' air.  a  vessel  sailing  toward  lock 

Decision-triggering  event,  pass  through  gates  clear  point  (7000) 

Resultant  action:  queue  vessel  exits  ^ueue.  Chamber  begins  recycle 
when  gates  a.e  cleared  Chamber  vessel  exits  to 

clearance  point  (7J00) 

7301  Throat  behind  chamber  vessel  .s  empty.  Queue  in  front  is 
empty.  Queue  in  bacx  is  not  empty.  Service  look-ahead  fea¬ 
ture  is  used,  Next  reach  does  not  contain  a  vessel  sailing 
toward  lock. 

7302  Throat  behind  chamber  vessel  is  empty.  Queue  in  front  is 
empty.  Queue  in  back  is  net  empty.  Service  look-ahead 
feature  is  ncc  used 

7j03  Throat  behir.a  chamber  ve-sel  is  empty  Queue  in  front  is 

empty.  Queue  m  oa.x  ;s  not  empty  Service  look-ahead  fea¬ 
ture  is  used  Next  reach  contains  a  vessel  sailing  coward 
lock  which  .annet  mo  .e  ont-  chamber  before  queued  vessel 
could. 

Sail  Across  Lake  (7100; 

7110  Vessel  enter*  .=.xe 

Exit  Lake  ( 7200) 

72iO  Vessel  exits  xaxe 

Sail  Through  Reach  (8j.0G; 

8101  Vessel  enters  reach 

Exit  Reach  (8200) 

8201  Vessel  exits  ied.n 

Enter  Port  (9100) 


9101 


Vessel  enters  pert 
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Exit  Port  (9200) 

9211  Vessel  selects  next  port  t/om  itinerary. 

9221  Vessel  enters  berth. 

9231  Vessel  selects  next  port  from  scheduler. 


3.  Error  Messages 

The  error  messages  produced  by  NETSIM/SHIP  are  interpreted  through 
four-digit  codes.  Each  error  codes,  along  with  its  cause,  is  given  below. 
Error  Number  Cause 


In  INITIALIZATION  ROUTINE: 


3001  A  FOR  EACH  PORT  statement  did  not  locate  a  port  whose 

identification  number  was  equal  to  that  of  the  vessel's 
current  node. 


In  MOVEMENT  CONTROLLER  routine; 

4101  A  FOR  EACH  PORT  statement  did  not  locate  a  port  whose 

identification  number  was  equal  to  that  of  the  vessel's 
destination. 

4104  In  searching  the  tirst  column  of  the  PARALLEL. FACILITIES 
TABLE,  nc  identiiication  number  was  found  which  matched 
that  given  by  the  TABLE. OF. NEXT. NODES. 

4105  The  variable  NEXT. FACILITY  obtained  from  the  FACILITIES, 
TABLE  does  not  match  any  reach,  lock,  or  lake, 

4106  No  identification  number  was  found  in  the  5th  column  or 
Pth  column  or  the  Lth  r~-w  of  the  PARALLEL. FACILITIES- 
TABLE  which  was  the  same  as  that  for  the  vessel's  current 
node 


In  ALTERNATIVE  -  SELECTOR  routine. 

4201  During  an  EDB  run,  one  alternative  within  a  set  was 

found  to  be  impassable  because  of  a  lock's  maximum 
vessel  size 


During  a  LOG  run,  every  alternative  within  a  set  was 
found  to  be  impassable  because  of  locks’  maximum  vessel 
sizes , 


4202 


102 


4203 

4204 

In  the 

5101 

5102 

In  the 

5201 

5202 

In  the 

5301 

5302 

5303 

5304 

5401 


In  searching  through  fcne  array  cf  expected  transit 
times,  no  match  was  found  fcr  the  least  expected 
t  z ans  *  .  t ime 

The  fa oi.ir.y  identification  number  given  ir.  the  D'h 
row,  F:h  column,  of  the  PARALLEL -FACILITIES  TABLE 
was  not  found  to  match  that  of  any  lock,  reach,  in¬ 
take  in  the  system 

ROUTINE  TO  SEARCH  TABLE  OF , NEXT  NODES : 

In  searching  the  first  row  cf  the  TABLE, OF, NEXT  NODES, 
no  id«r.rifi  ration  member  was  found  to  match  the 
argument  D 

In  searching  the  first  column  of  the  TABLE , OF  -  NEXT . 
NODES,  n;  identification  number  was  found  to  match 
-he  argument  C 

ROUTINE  TO  REFERENCE, FACILITIES, TABLE: 


In  searching  the  first  tow  of  the  FACILITIES  *  ID ■ I ABLE , 
no  idsn.„fi cation  number  was  found  to  match  the 

argument  B 

In  sea'-hitg  the  firs-:  •:  olumn  of  the  FACILIIj.ES  -  ID 
TABLE,  a.  j dentifi ration  number  was  found  co  mat-.n 
-he  a: g net.  A- 

ROUTINE  FOR  S ICCHA5 I. 1- TIME, CALCULATIONS: 


In  searcnxng  the  first  column  of  the  array  cf  Lake 
Eli  .osif  j  ciet.-.s ,  r.c  identification  number  was  iuuo.d 
“5  match  hui  cf  the  current  lake- 


In  searching  the  stray  of 
iden '  ij.L  :a  •.i  .r:  number  was 

.irret..'.  ea.h- 


xeach  ETT  coefficient;;  ,  no 
found  to  match  that  of  the 


j .n  sea:  -tiitg  one  array  of 
idea' n i ca  .:i cr  number  was 


lock  ETT  coeff icier.  :s ,  no 
found  tc  match  that  -t  the 


.'ir  ren  t 


.,i  on 


In  searching  the  array  of  parallel  set  ETI  ccel ti  .iencs , 
no  idem  if.;  car  ion  number  was  found  tc  march  that  of  the 

current.  yara.;.,e:  set. 


In  searching  the  array  of  arguments  for  a  static  nary 
chamber  entry,  nr  identification  number  was  iVur.d  it 
match  that  tt  the  current  lock. 
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5402 

5403 

5404 

5405 

5406 

5407 

5408 

5*09 

5410 

5411 

5412 

In  the 
5/01 


in  searching  'he  a r.c*y  of  aiguments  for  a  moving 
chamber  entry,  nc  identification  number  was  found 
to  match  that  ox  ;he  current  lock. 


In  searching  the  array  a  arguments  for 
bar  ent  ry .  no  identification  number  was 
mat  on  that  ol  the  current  lock. 


a  shore  oham- 
found  to 


In  searching  .he  array  of  arguments 
cycles  no  identification  number  was 
that  of  the  _urren>  lock. 


for  a  lock  re¬ 
found  to  match 


In  searching  the  array  of  arguments  for  a  look  process, 
no  idencifi.ation  number  was  found  to  match  that  of 
the  current  cock. 


In  searching  the  array  of  arguments  for  port  time,  no 
identification  number  was  found  to  match  that  of  the 
current  pert. 

In  searching  the  array  of  arguments  for  lake  transit 
times;  no  idenr ifi cat  ion  number  was  found  to  match 
that  cf  the  current  lake. 


In  searching  the  array  of  arguments  for  chamber  exit 
times,  no  .den: .tit at ion  number  was  found  to  match 
that  of  the  cu.ren..  lock, 


In  searching  the  array  of  arguments  for  look  exit 
times,  nc  ioer,  iticanon  number  was  found  to  match 
that,  cf  the  current  lock- 


It  searching  the  array  ci  aiguments  for  reach  transit 
times ,  .aen. if* -acccn  number  was  found  to  match 
that  of  the  our Ten;  reach. 

In  sea. .hung  ex (ay  ci  arguments  for  arrivse-tc- 
shot  t-en rry-pos- .it:,  times,  nc  identification  number 
was  i . ur.a  match  that  oi  the  current  lock 


In  searching  ins  array  or  arguments  for  queue-tc-shor t- 
encry-poaittcx.  r,mes,  no  identification  number  was 
i.tnd  co  match  that  of  the  current  lock. 


ROUTINE  TO  QUEXi  , S i  t< a.v £  DiSirUjCESIABiE 

in  searching  it-  iNIEAl-AXE- DISTANCES  TABiE,  no 
identiiiiStio.1  aumte..  was  round  to  match  that  given 
by  the  v»r:»b«  NXl.Nv.DE- 
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5702  In  seaicn.r.g  cr.e  i N I RAnAKE. DISTANCES .TABLE,  no 
idea: it i oat  ion  number  was  found  to  match  that  of  the 
current  vessel's  Current  node. 

5703  In  sear -hong  the  INIRaLaKE, DISTANCES. TABLE,  no 
Identities*. ion  number  was  found  to  match  that  cl  the 
cur  rent  iane 

In  the  ROUTINE  TO  ARRIVE  Al  ..OCR; 

6101  A  FOR  Each  END  CxCLE  statement  failed  to  find  an 
ENDCiClE  event  notice  for  the  current  lock  (the 
current  Lock  La  nut  now  processing,  although  there  is 
a  vessel  now  in  the  chamber) . 

6102  A  FOR  EACH  END  CiCLE  statement  failed  to  find  an 
END  ..CYCLE  event  notice  for  the  current  lock  (the 
current  it- tit  .  i  n_r  new  processing,  although  there 
is  a  vessel  new  in  the  chamber). 

6103  A  FOR  EACH  END-Crv.EE  statement  failed  to  find  an 
END  uitC.E  evert  nvf.ee  for  the  current  lock  (the 
current  .;.k  .»  n „ •  now  processing,  although  there  .a 
a  vessel  no*  ..a  me  .namberj. 

in  the  EVENT  TO  EXIT  QUEIE. 

6201  A  FOR  EAtH  nEoiN  t iCcE  statement  failed  to  rind  a 
BEGIN- EtCrE  event  notice  for  the  current  lock  (the 
chamber  .a  emr  -j  ,  uhen  to  the  side  opposite  the 
curren.  vesoai :  &nd  is  neither  now  recycling,  nor  now 
scheduled  to  oe6ir»  recycling)  . 

6202  A  FOR  EaCH  *Xv.R  e.acement  failed  to  find  a  lock  whose 
ldenciti-acruc  number  was  equal  to  that  given  by  the 
variable  i_GK-  .D- 

in  the  EVENT  TO  MOVE- 10  oROivI  Eiv’IRx  rObiTlON; 

b301  A  FoR  EAvH  .OCR  statement  failed  to  find  a  xtek  whose 

idem  in. scion  number  was  equal  to  that  given  by  the 
vasiaDit  iD  .R 

In  the  EVENT. TO. TRANS i I  IHRvAi, 

640x  A  FOR  EaCh  LOtR  statement  failed  to  find  a  lock  whose 

idea  till  number  was  equal  to  that  given  by  the 

vatiabre  iD-LGR. 

In  the  EVENT  TO. BEGIN  Cru.E. 

650i  A  FOR  EActi  lOv.K  sta cement  failed  to  find  a  lock  whose 

identities! ion  number  was  equal  to  that  given  by  the 
variable  .D  LR 
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In  the  EVENT. TO. END. CYCLE: 

6601  A  FOR  EACH  LOCK  statement  failed  to  find  a  lock  whose 

Identification  number  was  equal  to  that  given  by  the 
variable  LCK.ID. 

In  the  EVENT. TO. PASS. THROUGH  GATES, CLEAR. POINT: 

6801  A  FOR  EACH  LOCK  statement  failed  to  find  a  lock  whose 

identification  number  was  equal  to  that  given  by  the 
variable  LK ,  ID 

In  the  EVENT. TO. EXT. LAKE; 

7201  A  FOR  EACH  VESSEL  statement  failed  to  find  a  vessel  in 

the  set  ON  LAKE- TRAFFIC  whose  identification  number 
was  equal  to  that  given  by  the  variable  LAK,ID. 

In  the  EVENT. TO. LEAVE. REACH: 

8201  A  FOR  EACH  REACH  statement  failed  to  find  a  reach 

whose  identification  number  was  equal  to  that  given 
by  the  variable  REA. ID. 

In  the  EVENT. FOR. PORT, EXIT: 

9201  A  FOR  EACH  VESSEL  statement  failed  to  find  a  vessel, 

in  the  set  DOCK,  whose  identification  number  was 
equal  to  that  given  by  the  variable  ID.PRT. 


9203 


A  FOR  EACH  BERTH  statement  failed  to  find  a  berth,  in 
the  set  SET, CONTAINING, BERTHS,  whose  identification 
number  was  equal  to  that  given  by  the  variable  ID.PRT, 


